Здравствуйте, mrTwister, Вы писали:
T>Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева, возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке), мощная система разделяемых и наследуемых свойст и событий, event tunneling и event bubbling, мощнейшая система биндинга, позволяющая вообще отказаться от code-behind и полностью разнести логику пользовательского интерфейса с его внешним видом, система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно, очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании, очень сильная способность (круче, чем в HTML) создавать интерфейс со сложным и гибким layout'ом без привязки к пикселям и автоматически красиво подстраивающийся под любые размеры рабочей области, аппаратное ускорение.
Всё правильно, только опечатка, вместо WPF должно было быть Qt.
Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева, возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке), мощная система разделяемых и наследуемых свойст и событий, event tunneling и event bubbling, мощнейшая система биндинга, позволяющая вообще отказаться от code-behind и полностью разнести логику пользовательского интерфейса с его внешним видом, система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно, очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании, очень сильная способность (круче, чем в HTML) создавать интерфейс со сложным и гибким layout'ом без привязки к пикселям и автоматически красиво подстраивающийся под любые размеры рабочей области, аппаратное ускорение.
Здравствуйте, Cyberax, Вы писали:
x64>>>>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. C>>>Пиши на HTMLayout I>>Это из тех советов, которым следовать не стоит. C>Стоит заметить, что твоим советам стоит следовать. Только выполнять их наоборот.
Без преувеличения можно сказать что WPF это уже устоявшаяся технология,а твой лаёут эт вечно подростковый Nextgen, которы будет таким и через 10 лет. Мало написать либы. Нужна поддержа со стороны IDE и много чего еще.
Как обычно срач перешел в плоскость Linux vs. Windows, поэтому не могу не высказаться(зудит у меня в одном месте).
Итак, приступим. Тут много копий сломано по поводу Qt vs WPF. Сказать могу одно — под Windows однозначно лучше WPF нету. Тыкать qml мне в лицо и другие части тела не надо, я json синтаксиса на десктопе не понимаю. Возможности у систем сравнительно одинаковые, но дьявол, как обычно, таится в деталях.
Даже не детали, а так, детальки.
1. XAML богаче QML по декларативным возможностям.
2. XAML расширяем.
3. XAML является открытым стандартом (пруфлинк), который никто не мешает реализовать для любого языка и любой платформы. Может ли этим похвастаться QML, честно говоря, не знаю.
4. Анимация WPF покрывает практически все распространенные сценарии, причем в большинстве случаев она задается через XAML.
Аргументы, приводившиеся тут до меня, приводить не буду, ибо Шеридан, скорее всего, MVVM никогда на практике не применял . Ну да лан. Далее. В пользу WPF играет такой немаловажный фактор, что это единственная на данный момент платформа, в которой разработку UI layout можно полностью отдать на откуп дизайнеру. И ведь разработает, не написав ни строчки кода.
5. Сценарии валидации. Тема как-то обойдена предыдущими ораторами, однако валидация данных в WPF развита достаточно сильно(если не считать известных граблей, пользоваться ей удобно).
6. WPF подталкивает программиста к таким вещам, как: включение мозга, использование правильных(модных в данный момент) паттернов при разработке UI(ибо хорошо они ложатся на технологию), опять же, воображение развивает. А главное, практически нет технических ограничений в реализации замысла.
7. Про баги WPF(чтобы быть объективным). На данный момент(3.5 sp1) в WPF имеют место быть следующие проблемы:
— Отрисовка шрифтов. Тема весьма и весьма больная и является основным нареканием по поводу качества WPF. В 4.0 пофиксили.
— Баги с валидацией. Имеют место быть, но существуют воркэраунды. В 4.0 вроде пофикшено.
— Баги с чтением XAML в определенных случаях.Скорее всего вы на них не натолкнетесь. Это я вечно собираю все грабли на своем пути.
Наверное, есть и еще(куда ж без них), но критичным багом является только первый из вышеперечисленных, ибо требует определенных приемов на избежание, например, дрожания шрифта при нажатии кнопки.
Дальше можно развести флейм по поводу управляемых/неуправляемых сред для разработки UI, и почему управляемые лучше, но не буду.
Заключение. WPF в целом является зрелой технологией, пригодной для коммерческого использования. Однако многих останавливает инерционность мышления и сложность перестройки на иные принципы проектирования UI. Мы привыкли опираться на прошлый опыт. Тут он помогает весьма слабо. Qt с моей точки зрения является технологией эволюционной, а не революционной, ибо стиль мышления не меняет.
З.Ы. Да, WPF не кроссплатформенна, что, однако, не мешает ей оставаться лучшей платформой для разработки UI под Windows(по совокупности множества факторов).
З.Ы.Ы. Фор Линукс троллз онли. Как же я ненавижу Линукс
Не хотел влезать но раз уж меня тут поминают заочно ...
XAML разрабатывался для того чтобы быть использованным в IDE. Я подозреваю что немалая толика доходов уважаемой компании (NB: без кавычек) поступает от средств разработки, т.е. одна из причин почему XAML получился именно такой является достаточно приземленной.
Руками писать XAML никто изначально не собирался. А тем более его "учить".
Я уже как то раз говорил что XAML это XML сериализация того что раньше использовал VB в файлах описания форм (.frm).
В общем-то всё узнаваемо. Т.е. ожидать чего-то волшебного от XAML самого по себе не надо. И учить его в общем-то тоже не надо — это XML.
То что реально надо учить так это сам набор элементов/классов который сериализуется в XAML.
Т.е. надо знать что есть такая/такое <StackPanel> а у него есть Margin="12,6,12,12", что есть <ListView Name="lineItemListView" и т.д.
"Выучить" это все невозможно в принципе ибо каждый новый класс (widget) — это свой набор методов и свойств.
Т.е. markup (т.е. структура) объектов на экране строго отделена от стилистики. В моем примере я специально выделил то что стили имеют разные значения
для разных media. Для visually impaired people один стиль для всех остальных — другой. Для печати того же самого DOM — третий.
И это я считаю правильно. Собственно это и была одна из причин почему я выбрал HTML/CSS как языкы разметки/стилирования для UI.
Чем дальше мы с этим всем работаем тем больше убежденность что это правильный путь. Но есть одно "но", а именно:
WYSIWYG редактирование и IDE.
Скажу сразу что в HTML/CSS с WYSIWYG плохо. Если ты видишь текст "Expenses.NET" белого цвета то этот цвет может получиться миллионом разных способов.
Т.е. select-element-and-set-property-color в общем случае сделать нельзя вменяемым образом.
В XAML с этим лучше — выбрал элемент и сказал ему Foreground="White". Но это палка о двух концах ибо:
CSS, Cascading Style Sheets.
Это хорошо и правильно. Для UI например это означает что ты можешь использовать разные themes для одного и того же DOM.
Это означает что поддержка скажем high contrast или text selection элементов UI это сугубо декларативные фичи не требующие менять код живого приложения.
Ну и далее:
Поддержка Design Time.
При разработке виджетов для WPF приходится заботится о поддержке Design Time функциональности. Иногда это достаточно большой объем (если правильно все делать) кода который еще к тому же попадает в runtime где ему совершенно нечего делать. В качестве алтернативы в HTML используется ...
Простой набор сущностей.
В HTML/CSS ты оперируешь всего тремя основными объектами:
Универсальный DOM Element, набор свойств стилей и behavior — code behind DOM Element который превращает элемент в option box или list box.
Т.е. сущностей всего ничего поэтому потребность в вещах типа intellisense вообще говоря нужна в первые два-три дня.
Ну в самом деле DOM Element это примерно 30 методов — меньше чем функций в C runtime.
Чего там intellisens-ить?
Ну и есть еще такая штука как CSS Selectors.
На самом деле народ воспринимает CSS Selectors как данность но это реально язык запросов к UI.
Вот тебе управляемый data binding:
function onDataChanged(data)
{
for( var element in self.$$([bound-with="some-data-source-name"]) )
element.text = data;
}
Что означает: при изменении коакой-то data пройдись по всем элементам с атрибутом bound-with="some-data-source-name"
и поменяй их текст на новый. При этом ты можешь имплементировать всяко разные логики этого data binding, а не только
те что предусмотренны создателями framework.
Здравствуйте, Ikemefula, Вы писали:
I>>>Я уже посмотрел и не нашел ничего кроме одной крепкой либы. Ровно либа, до технологии как до небес. C>>Смотрел, но не увидел. I>Демок нет, но технология есть Ну и цирк. Все надо делать вручную — и это технология ?
Твой кретинизм достаёт. Скачай HTMLayout и посчитай количество демок там. Их в районе 200 — более чем достаточно.
Просто нет одной большой демы, которая бы показывала сразу большинство функций.
C>>Т.е. специально для тебя, нужно сделать функции с 20-ю параметрами? I>Не нужно. Сделай демки, выложи проекты, в т.ч. на джаве, напиши доки, статьи, пусть несколько контор построят на этом бизнес, если это получится — есть надежда на технологию.
Я уже приводил примеры огромных контор, которые строят на HTMLayout свой бизнес. Что касается остального — работаю над этим.
C>>Технология в HTMLayout — это HTML+CSS. Ничуть не менее сложная или менее продвинутая, чем тот же WPF. Просто HTML+CSS — это СТАНДАРТНАЯ технология, её не надо специально для HTMLayout учить. I>При этом HTML+css Не может конкурировать с WPF.
Ещё как может.
I>На это претендует HTMLLayout а ему в свою очередь до технологии как до небес.
Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
Здравствуйте, squid, Вы писали:
S>он малопригоден для игр по своей идеалогии. а вообще, штука очень мощная. полгода с ней работал. что касается кубика — загрузи любую другую модель и ее крути))) S>так что, слив по полной как только о 3D речь заходит? а что в вашем стане с эффектами при помощи шейдеров?
3D нет и не планируется, так как он на практике не нужен. Есть очень качественный 2D с эффектами, в том числе и 3D-подобными.
RO>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt.
VD>>Ага. Только жаль, что приложения на нем получаютя убогими. Но в этом, очевидно, виноваты кривые руки...
RO>Не жаль. Если разработчики настолько зациклены на майкрософтовских технологиях, которые работают только в одной ОС
Если эта ОСь занимает 90% десктоп-рынка, то как-то пофиг, не?
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Данный каммент лишь от жадности.
Но от жадности, ква-ква,
И от скупости,
Но от подлости, ква-ква,
И от глупости,
И еще от хвастовства,
Ква-ква-ква, да ква-ква-ква,
Не поможет твой товар,
Злой, противный Дуремар!
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
T>>ИМХО, у WPF главная проблема — это высокий порог вхождения.
Не в этом дело. Просто налицо несколько перекрывающих функциональность друг друга абстракций, и разработчики порой как те ослы у двух стогов сена, только здесь стогов больше. Особенно проблема заметна в отсутствии нескольких действительно нужных абстракций, например реализации отдельно скинов (аналога CSS), есть шаблоны представления, шаблоны данных и т.д., но нет шаблонов-шаблонов представлений, к которым привыкли в вебе, и это реально неудобно. Я бы еще добавил, что нет шаблонов-шаблонов данных, наподобие динамической раскраски ячеек Excel в зависимости от данных. Т.е., все это легко реализовать в конкретном шаблоне представления или шаблоне данных, вбить в дизайн гвоздями (или же косвено через ресурсы, не суть), но на лету менять такие "скины данных" — этого встроенного нет. Разумеется, можно писать самим, как внешнюю либу, и таких велосипедов уже хватает, но вот тут и встает такой момент, что было бы неплохо, чтобы этот тул гладко вошел во взаимодейтствие со всеми остальными абстракциями и своими велосипедами.
I>Не у WPF, а у декларатвного и функционального программирования вообще.
Ну, у тех, у кого есть опыт десктопного+вебового GUI, WPF особой сложности не представляет, так что не изобретай и не пальцуйся перед коллегами, тем более, что GUI на XML во многих других GUI либах рисуют около десятка лет.
I>Винформс это вагон граблей и отсутствие методов решения. Например Ownerdraw есть сплошная проблема из за отсутсвия мало-мальского механизма отрисовки.
Owner draw был введен в win32 контролы для кастомизации их внешнего вида, а не создания других контролов на их основе. Ты не забыл, что сообщение идет паренту, а не самому себе? Это ключ к пониманию концепции, которая банальна в общем-то. Если в этой простой модели и может быть какая-то проблема, то лишь из-за лени разработчиков, экономящих на спичках, т.е. поленившихся написать контрол практически с 0-ля, и предпочитающих бороться с развитой функциональностью базовой оконной процедуры, вместо написания своей.
А вообще, сравнивать GDI, которому около 30-ти лет, и WPF крайне глупо. Для своего времени, сервис ОС по перерисовке элементов управления был способом создавать маленькие бинарные образы и нетребовательные к ресурсам приложения, т.к. прилична была доля кода, которая шарилась м/у приложениями через системные DLL. Именно потому графический UI Windows 3.1 на 386-х просто летал, а на линуксный GUI на тех же машинах хотелось лишь пристрелить, чтобы не мучался.
Т.е. это все верно было для случая, когда требуемая кастомизация отображения стандартных контролов минимальна, желательно — вообще отсутствует, как во всех системных утилитах виндов. В случае же желания рисовать все "с чистого листа", сервисы рисования ОС только мешают, в этом плане любая библиотека с собственной отрисовкой будет лучше GDI, и не потому, что GDI плохой, а потому что забыли озвучить требования перед обсуждением.
Здравствуйте, Cyberax, Вы писали:
I>>Демки слабые и демонстрируют убожество. C>Заглянул в MSDN. Демки слабые и демонстрируют убожество WPF.
При этом они
1. есть
2. доступны в два три клика
3. не требуют геморроя и лишних телодвиженй
А убожество WPF сильно спорный момент.
C>>>Просто нет одной большой демы, которая бы показывала сразу большинство функций. I>>Просто нет еще технологии, а есть всего лишь либа. C>Ну да. У Технологии должны обязательно быть функции с 20-ю параметрами и тонной макулатуры.
Это в твоей конуре для технологии надо функции с 20ю параметрами.
I>>Бизнес они на другом строят, а лайоут просто используют. Твой мега-мозг уже давно перегрелся, что бы это понять. C>А, то есть WPF нельзя использовать, на нём можно только Строить Бизнес. Понятненько.
WPF используется разными конторами но также вокруг него строится бизнес.
I>>И в каой версии html+css появился биндинг? C>Где-то со второй, в конце 90-х. Смотри на http://www.w3schools.com/htmldom/default.asp — в HTMLayout используется оно.
Это мягко говоря отстой а не биндинг.
I>>Я лично не дождался того что просил показать. Так что кто сдулся, тот еще вопрос. C>ЧТО ТЫ ПРОСИЛ ПОКАЗАТЬ??? Мне так никто и не удосужился ответить.
Вероятно твой кретинизм мешает поднять забрало да посмотреть.
Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. Т.е. вообще как-то странно получается, вроде занимаемся визуальным программированием, но при этом по-прежнему приходится ковырятся в каком-то (при чём незнакомом) языке. И возникает закономерный вопрос — а есть ли в этом XAML что-нибудь, что может заставить обычного шароварщика, скажем, писать свой UI именно под WPF? Особенно учитывая, что софт какой-нибудь системный больше и не требует никаких особых красивостей. Может быть там какие-то контролы есть новые на замену обычным системным? Что там такого есть, ради чего стоит таки потрахаться как следует с WPF-дизайнером и этим грёбанным XAML? Может хоть ссылочку дадите для начинающих в WPF? Особенно для тех, кто на него с WinForms переходит. Я пока даже не уверен вообще надо ли оно мне. Отговорите, а?
Здравствуйте, mrTwister, Вы писали:
RO>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. T>Что из этого есть в Qt?
Так и знал — стоит написать что-нибудь по делу (см. первое сообщение выше), так тишина, а как только пощекотать чье-нибудь ЧСВ, так сразу же будет ответ, и не один :-).
Отвечая на вопрос, есть всё. WolfenQt видел?
Архитектурно Qt сделана не так и красиво, но очень уж много всего интересного умеет.
Кстати, T>>очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании
загляни в соседний флейм, где превозносят майкрософтовские средства разработки за то, что там можно всё мышью сделать :-).
Здравствуйте, Cyberax, Вы писали:
I>>Я уже посмотрел и не нашел ничего кроме одной крепкой либы. Ровно либа, до технологии как до небес. C>Смотрел, но не увидел.
Демок нет, но технология есть Ну и цирк. Все надо делать вручную — и это технология ?
I>>Я привык к технологиям. C>Т.е. специально для тебя, нужно сделать функции с 20-ю параметрами?
Не нужно. Сделай демки, выложи проекты, в т.ч. на джаве, напиши доки, статьи, пусть несколько контор построят на этом бизнес, если это получится — есть надежда на технологию.
C>Технология в HTMLayout — это HTML+CSS. Ничуть не менее сложная или менее продвинутая, чем тот же WPF. Просто HTML+CSS — это СТАНДАРТНАЯ технология, её не надо специально для HTMLayout учить.
При этом HTML+css Не может конкурировать с WPF.
На это претендует HTMLLayout а ему в свою очередь до технологии как до небес.
Здравствуйте, Ikemefula, Вы писали:
C>>Скачай HTMLayout и посчитай количество демок там. Их в районе 200 — более чем достаточно. I>Для тупых, еще раз — все было скачано и посмотрено. I>Демки слабые и демонстрируют убожество.
Заглянул в MSDN. Демки слабые и демонстрируют убожество WPF.
C>>Просто нет одной большой демы, которая бы показывала сразу большинство функций. I>Просто нет еще технологии, а есть всего лишь либа.
Ну да. У Технологии должны обязательно быть функции с 20-ю параметрами и тонной макулатуры.
C>>Я уже приводил примеры огромных контор, которые строят на HTMLayout свой бизнес. Что касается остального — работаю над этим. I>Бизнес они на другом строят, а лайоут просто используют. Твой мега-мозг уже давно перегрелся, что бы это понять.
А, то есть WPF нельзя использовать, на нём можно только Строить Бизнес. Понятненько.
I>>>При этом HTML+css Не может конкурировать с WPF. C>>Ещё как может. I>И в каой версии html+css появился биндинг?
Где-то со второй, в конце 90-х. Смотри на http://www.w3schools.com/htmldom/default.asp — в HTMLayout используется оно.
I>>>На это претендует HTMLLayout а ему в свою очередь до технологии как до небес. C>>Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода. I>Я лично не дождался того что просил показать. Так что кто сдулся, тот еще вопрос.
ЧТО ТЫ ПРОСИЛ ПОКАЗАТЬ??? Мне так никто и не удосужился ответить.
Здравствуйте, x64, Вы писали:
x64>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. Т.е. вообще как-то странно получается, вроде занимаемся визуальным программированием, но при этом по-прежнему приходится ковырятся в каком-то (при чём незнакомом) языке. И возникает закономерный вопрос — а есть ли в этом XAML что-нибудь, что может заставить обычного шароварщика, скажем, писать свой UI именно под WPF? Особенно учитывая, что софт какой-нибудь системный больше и не требует никаких особых красивостей. Может быть там какие-то контролы есть новые на замену обычным системным? Что там такого есть, ради чего стоит таки потрахаться как следует с WPF-дизайнером и этим грёбанным XAML? Может хоть ссылочку дадите для начинающих в WPF? Особенно для тех, кто на него с WinForms переходит. Я пока даже не уверен вообще надо ли оно мне. Отговорите, а?
T>Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева, возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке), мощная система разделяемых и наследуемых свойст и событий, event tunneling и event bubbling, мощнейшая система биндинга, позволяющая вообще отказаться от code-behind и полностью разнести логику пользовательского интерфейса с его внешним видом, система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно, очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании, очень сильная способность (круче, чем в HTML) создавать интерфейс со сложным и гибким layout'ом без привязки к пикселям и автоматически красиво подстраивающийся под любые размеры рабочей области, аппаратное ускорение.
Здравствуйте, Ikemefula, Вы писали:
I>Я конкретно хочу услышать следующее — на WPF Нельзя сделать А и Б по причине В.
На ‹вставить название сюда›, если можно нарисовать прямоугольник и управлять цветом пикселей, можно сделать всё.
I>Пока что твои ролики покзывают то, что мой товарищ сделал где то год назад.
Здравствуйте, Ikemefula, Вы писали:
I>Нужны фичи для HTMLLayout. Могу я в твоем html+css редакторе налепить например примитивов для векторной графики и ожидать, что в коде интеллисенс мне все это подскажет. Или же наоборот, в код налепить всякгого, а потом при редактировании html получать помощь в виде того же интеллисенса и разумеется все это при работе с примитивами
Интересный однако у вас стиль кодинга, налепить, наколбасить всякого, а потом смотреть, что же их этого вышло, и причем, для того, чтобы разобраться в том, что получилось, интеллисенс жизненно необходим
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, VladD2, Вы писали:
RO>>Всё правильно, только опечатка, вместо WPF должно было быть Qt.
VD>Ага. Только жаль, что приложения на нем получаютя убогими. Но в этом, очевидно, виноваты кривые руки...
Не жаль. Если разработчики настолько зациклены на майкрософтовских технологиях, которые работают только в одной ОС, то пусть плачут, колются и пишут и используют убогие приложения.
f>> RO>>>Плохо настроены, надо полагать. FreeType-то один на всех. f>> F>> А почему Gtk это делает нормально? f>> RO>Хорошо настроена, надо полагать. f>> Т.е. реально использовать Qt нельзя.
S>КО опять подсказывает: S>Надо бы настроить...
КО подсказывает, что в 2010-м году уже как бы не хотелось настраивать отдельно Qt, отдельно GTK, отдельно еще что-то...
Здравствуйте, x64, Вы писали:
x64>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. Т.е. вообще как-то странно получается, вроде занимаемся визуальным программированием, но при этом по-прежнему приходится ковырятся в каком-то (при чём незнакомом) языке. И возникает закономерный вопрос — а есть ли в этом XAML что-нибудь, что может заставить обычного шароварщика, скажем, писать свой UI именно под WPF? Особенно учитывая, что софт какой-нибудь системный больше и не требует никаких особых красивостей. Может быть там какие-то контролы есть новые на замену обычным системным? Что там такого есть, ради чего стоит таки потрахаться как следует с WPF-дизайнером и этим грёбанным XAML? Может хоть ссылочку дадите для начинающих в WPF? Особенно для тех, кто на него с WinForms переходит. Я пока даже не уверен вообще надо ли оно мне. Отговорите, а?
Как уже сказал mrTwister, WPF сейчас хорошо подходит там, где достаточно сложный интерфейс, если под сложностью понимать комбинирование различных визуальных элементов. WPF сильнее WinForms, если активно используются data binding, а также такой паттерн как MVVM. Плюс, система свойств WPF (dependency property) позволяет настраивать контролы под свои специфические нужды без наследования (это я про attached behavior). В WPF нет нативных контролов, все контролы в WPF написаны на C#, а их визуализация осуществляется низкоуровневым Media Integration Layer (нативная DLL), по сути надстройкой над DirectX. Кстати, в WPF можно создавать свои шейдерные эффекты. А так, разница между WPF и WinForms настолько велика, что в один постинг то не уместить.
В-общем, думаю лучше спросить что-то более конкретное. И потом, насколько я понял, MS таки собирается двигать WPF как ведущую технологию для Windows GUI.
Здравствуйте, c-smile, Вы писали:
CS>Не хотел влезать но раз уж меня тут поминают заочно ...
CS>XAML разрабатывался для того чтобы быть использованным в IDE. Я подозреваю что немалая толика доходов уважаемой компании (NB: без кавычек) поступает от средств разработки, т.е. одна из причин почему XAML получился именно такой является достаточно приземленной.
Что именно ты понимаешь здесь под "IDE"? Навороченный дизайнер типа бленда? Тогда ты не прав. Всё, что нужно для реактирования ксамла — это текстовый редактор ("програмерский", с фичами типа отступов, подсветки и т.п.) + интеллисенс + немного валдации (есть ли такое свойство, такой ресурс и т.п.). Навороченный дизайнер ни разу не нужен. Максимум — некое preview в режиме только для чтения. В этой нише многим вполне по силам потягаться с Майкрософтом.
CS>Руками писать XAML никто изначально не собирался.
Именно "писать руками" XAML — самый удобный способ разработки.
CS>А тем более его "учить".
А учить всё-таки немного нужно. Запоминать — нет (интеллисенс и хорошая валидация тут бы помогли), но помнить некоторые паттерны, некоторые особенности, помнить имеющийся инструментарий (например, какие есть баиндинги и триггеры) нужно.
CS>Я уже как то раз говорил что XAML это XML сериализация того что раньше использовал VB в файлах описания форм (.frm).
Типа того, но плюс ещё такие совсем не маловажные пункты, как расширяемость и гибкая где-то возможность управления сохранением; возможности связывания элементов; возможность повторного использования.
CS>В общем-то всё узнаваемо. Т.е. ожидать чего-то волшебного от XAML самого по себе не надо. И учить его в общем-то тоже не надо — это XML.
Это совсем не xml, если говорить не о том, как оно выглядит, а о том, что из себя представляет.
CS>То что реально надо учить так это сам набор элементов/классов который сериализуется в XAML. CS>Т.е. надо знать что есть такая/такое <StackPanel> а у него есть Margin="12,6,12,12", что есть <ListView Name="lineItemListView" и т.д. CS>"Выучить" это все невозможно в принципе ибо каждый новый класс (widget) — это свой набор методов и свойств.
Надо учить, что, например, в триггерах стиля доступен один функционал, а в триггерах шаблона — другой. И многие другие подобные "мелочи".
CS>Теперь касательно XAML и HTML/CSS.
CS>Вот эта конструкция (XAML):
… CS>В HTML/CSS разделяется на две части: CS>HTML
… CS>и стили:
… CS>Т.е. markup (т.е. структура) объектов на экране строго отделена от стилистики. В моем примере я специально выделил то что стили имеют разные значения CS>для разных media. Для visually impaired people один стиль для всех остальных — другой. Для печати того же самого DOM — третий. CS>И это я считаю правильно. Собственно это и была одна из причин почему я выбрал HTML/CSS как языкы разметки/стилирования для UI.
Ну и в чём тут отличие от XAML? В том, я могу судить, что ты или специально или по не знанию, не разделил описание стиля и описание поведения от, собственно, инстанцирования и применения заданного стиля Всё тоже самое доступно и в XAML, но с другим синтаксисов. Несомненно, в чём-то синтаксис (и структура организации) HTML/CSS лучше/удобнее XAML, в чём-то наверняка нет, а суть в том, что функционально они … инструменты одного порядка, никто из нах не на порядок лучше другого.
CS>Чем дальше мы с этим всем работаем тем больше убежденность что это правильный путь. Но есть одно "но", а именно: CS>WYSIWYG редактирование и IDE. CS>Скажу сразу что в HTML/CSS с WYSIWYG плохо.
В XAML тоже.
CS>Извиняюсь за длинное сообщение.
Ничего. По судя по этому сообщению, ты или мало знаешь о XAML и о том, как его можно и нужно правильно применять, или намеренно не используешь XAML так, что бы было просто и удобно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, dr.Chaos, Вы писали:
DC>Да там текст двух файлов рендериться со сглаживанием, т.к. этому .NET приложению пофиг на установки RDP. А вообще при прокрутке текста, в любом случае должно перерисовываться все поле вывода или, как минимум, его большая часть.
Угу, поэтому мы в своем протоколе округляли цветовые составляющие до 4:4:4 бит, после этого даже шрифты со сглаживанием сжимаются вполне и вид субъективно не страдает. Сам факт такого округления заметен только на больших пространствах с плавным градиентом, что как бы не принципиально для клиентов. Что интересно, с таким округлением трафик получается даже меньше чем у TightVNC, а у того, в свою очередь, гораздо меньше, чем у RDP.
Здравствуйте, x64, Вы писали:
x64>Мда. Похоже, что мне ничего этого не нужно.
Ты знаешь, я тоже так думал, пока не начал этим пользоваться
ИМХО, у WPF главная проблема — это высокий порог вхождения. Разница в сложности между WinForms и WPF просто огромная. Ситуация осложняется всё еще сыроватостью технологии и отсутствием наработанных и проверенных паттернов. Даже у идеологов нет пока единого мнения, как кошерно делать интерфейс на WPF, использовать ли MVVM и как разделить обязанности между View и ViewModel. Короче, есть над чем голову поломать. У WinForms главное преимущество — это то, что там все просто, понятно, граблей минимум и они давно известны.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Ikemefula, Вы писали:
RO>>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. A>>>а по глюкам с qt оно сравнимо? A>>>я просто c qt дела-то имею, а с wpf [пока] нет. I>>глюки есть. Тем не менее, глядя в демки, qt до wpf как до луны пешком. QT хорошо конкурирует с Winforms&GDI+ A>меня больше интересуют не глюки вроде "не удалось нарисовать хитровывернутый контрол", а "зависает ни с того ни с сего"
У нас проект разрабатывается на WPF уже полтора года. За это время "шаловливые ручки" залезли во многие возможности WPF и чего чего, а зависаний не было ни разу. А вот если ты подразумеваешь тормоза, то WPF безусловно достаточно требовательна. Однако, смею предположить, что после внедрения сей технологии в Visual Studio оптимизации будут делаться активнее.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>>>Где-то со второй, в конце 90-х. Смотри на http://www.w3schools.com/htmldom/default.asp — в HTMLayout используется оно. I>>>>Это мягко говоря отстой а не биндинг. C>>>Не WPF-овцам об этом говорить... MK>>Не мог бы ты подробнее написать об этом? Только без ссылок на "трели". Давай лучше своими словами: что так убоги биндинги WPF? C>Очень примитивные.
C>Представь такую модельную ситуацию, есть элемент управления "дерево файловой системы", который отображает структуру каталогов и файлов. Всё абсолютно стандартно, никаких проблем.
C>Теперь в этот элемент добавляем label, в котором показывается размер на диске выбранного элемента и всех его детей. Тоже никаких проблем.
C>Теперь добавляем поддержку событий. Т.е. нам от операционной системы приходят оповещения "файл blah_blah изменился". Как мне сделать так, чтобы label с общим размером выбранного элемента корректно пересчитывался?
C>Или ещё усложним ситуацию — узлы дерева делаем редактируемыми (можно переименовывать файлы). Начинаем редактировать имя, а тут кто-то меняет имя родительского каталога. Как это обработать красиво?
Погоди, погоди. Не надо вопросом на вопрос. Давай лучше ты скажешь, как эти задачи можно было бы решить, и где это уже сделано. Не надо меня озадачивать. Тем более, что на мой взгляд, приведенные тобою проблемы совершенно не проблема и нормально решается в MVVM.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Засечки — это результат традиции. И идёт эта традиция из сложностей деланья букв на поверхностях
Что? А древние римляне, отливая буквы в бронзе, выбивая надписи на колоннах, использовали засечки, потому что так проще? Или средневековые писцы вырисовывали засечки, потому что писать без них сложнее?
SV.>>>«Елочки» с „лапками“ служат той же цели. Текст с ними проще, быстрее и приятнее читать, чем с чужеродными для русского текста верхними кавычками. YKU>О, начинается... Чужеродные кавычки и исконно-потосконные лапки... Давайте еще пофлеймим о важности дефиса вместо тире(не путать с минусом!).
Я всегда ставлю кавычки и тире, где нужно, из уважения к читателю. От других того не требую. Кто скажет, что так читать менее удобно, чем с ASCII-кавычками, в того я первый брошу камень.
RO>>Кстати, правильная форма букв для русского языка важнее, чем для английского. Сравни: RO>>abcdefghijklmnopqrstuvwxyz RO>>абвгдежзиклмнопрстуфхцчшщъыьюэя
YKU>Жульничаете. Где й, где ё? По читабельности — те-же "хвостики".
Согласен, «й» зря пропустил, а вот «ё» редко пишут.
RO>>У русских букв намного меньше «хвостиков» YKU>10 в английском и 7 в русском(если считать все буквы, а не только те, что вы написали).
Девять в русском, если считать и «ё» и «й», и «ц» и «щ». Но они на непопулярных буквах.
YKU>Это "намного"?
Намного. С учетом частоты букв — втрое. Возьмем два относительно современных текста: «Gone with the Wind» для английского языка и «Мастера и Маргариту» для русского.
Английский текст: 1751 тысяча букв, из них 726 тысяч строчных с «хвостиками». 41%.
Русский текст: 598 тысяч букв, из них 83 тысячи строчных с «хвостиками». 14%.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Всё правильно, только опечатка, вместо WPF должно было быть Qt.
Осталось добавить что-нибудь про Белазы, грибы и Мерседесы — сходство с одним известным товарищем стало бы стопроцентным.
Здравствуйте, Ikemefula, Вы писали:
x64>>>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. C>>Пиши на HTMLayout I>Это из тех советов, которым следовать не стоит.
Стоит заметить, что твоим советам стоит следовать. Только выполнять их наоборот.
Здравствуйте, Cyberax, Вы писали:
I>>Чушь. А время существования никого не интересует. C>Сам что-то заблеял про "подростковый nextgen". Это WPFу надо ещё из возраста CoolKids вырости.
Время существования никого не интересует. WPF уже поддерживается многими инструментами, а твой мега-продукт вобщем то ничем.
I>>html это слишком мало. Любой редактор не сможет обеспечить например хотя бы тот же интеллисенс. C>Ну так кто мешает? Я вот пишу код для HTMLayout на Java, с IntelliSense'ом и прочими радостями.
Покажи это чудо.
C>А интерфейс — на HTML+CSS, как и надо. Кстати, там тоже IntelliSense с рефакторингом работает — у меня же не текстовый редактор, а нормальная IDE.
Т.е. уже не любой редактор хтпл а таки нормальная иде ? Т.е. ты пургу гнал ?
Здравствуйте, Ikemefula, Вы писали:
C>>Там всё делается. В теории. Точно как и на WinForms. I>Я правильно тебя понял, в QT, теоретически, делается все тоже самое, что и в WPF, но точно так же как и на WinForms, что означает QT работает ровно так же,через анус, как и winforms ?
Нет. Я говорю, что теоретически WPF, WinForms и QT эквивалентны. На них всех можно сделать всё что угодно.
Разница только в удобстве и количестве работы. QT, WPF и HTMLayout сейчас примерно в этом отношении одинаковы.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Codechanger, Вы писали:
RO>>>>На ‹вставить название сюда›, если можно нарисовать прямоугольник и управлять цветом пикселей, можно сделать всё.
I>>>Это такой демарш ?
C>>В принципе он прав. Вопрос только в количестве времени, которое на это надо убить. С WPF мало, с какими-то другими технологиями, возможно, и на порядок(в 10 раз) больше.
I>А местами даже на два порядка больше. Про то и речь. Посему странно слышать про прямоугольник и управление цветом пикселей.
Ну тут как бы надо договориться о критерии превосходства одной технологии над другой. Пока спор идет в ключе "а чего есть там, чего нету тут", то спор длится бесконечно. А как только в дело вступают такие параметры, как время реализации, легкость модификации и т.д., то тут можно поговорить конкретно.
Здравствуйте, Ikemefula, Вы писали:
x64>>>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. C>>Пиши на HTMLayout I>Это из тех советов, которым следовать не стоит.
Когда уже в Janus появится "пометить все ответы пользователя как прочитанные (и больше не скачивать их вовсе)"?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Cyberax, Вы писали:
C> Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
Подожди, сейчас тебе напишут о текст боксе, с видео в бакграунде, вращающемся по часовой стрелке
Здравствуйте, Roman Odaisky, Вы писали:
RO>FreeType кажется какой-то чуждой, хотя эти продукты на порядок лучше того, что используют в MS.
FreeType на малых разрешениях сливает TrueType, а в больших уже не принципиально.
RO>Насчет преимуществ: я, естественно, не использовал ни то, ни другое, но, насколько я знаю, WPF — единственная виндовая технология, которая правильно отрисовывает мой простенький типографический тест: http://qwertty.com/tmp/ScreenTypographyTest.html.
Правильно, от того текст в WPF плохочитабелен, ибо требовать "правильно отрисовывать" этот тест на <300 DPI — более чем глупо. На таких разрешениях нужна читабельность, а не точность позиционирования.
Здравствуйте, fddima, Вы писали:
F>>> Почему все Qt приложения криво рендерят шрифты под Gnome? RO>>Плохо настроены, надо полагать. FreeType-то один на всех. F> А почему Gtk это делает нормально?
Здравствуйте, vdimas, Вы писали:
I>>Правильно так — отрисковка в оконной системе виндов построена на GDI. Но сама оконная система виндов не сводится к отрисовке и потому в корне неверно утверждать что она построена на GDI.
V>Ну да, помимо отрисовки сама оконная система сводится еще к функциональности самой оконной системы.
Нет, речь идет о "Windows provides three main categories of objects: user interface, graphics device interface (GDI), and kernel."
V>Не надоело подставляться?
Здравствуйте, SV., Вы писали:
SV.>Субпиксельный рендеринг как способ отобразить на мониторе шрифт похожим на тот же шрифт, но напечатанный в типографии — маргарин вместо масла, безвкусный, дешевый и вредный для здоровья заменитель. Хотя преподносится некоторыми как передний край прогресса. Преподносится, кстати, теми же людьми, которые рисуют лапки вместо старых добрых "". Что касается переднего края прогресса — им будет монитор, dpi которого достаточно, чтобы без жалких уловок рисовать что угодно и как угодно, в том числе шрифты малым кеглем и изысканными гарнитурами.
Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI.
А засечки и правильная форма важна из-за того, что она эволюционировала долгие столетия, и её реально удобнее читать.
SV.>Интересно то, что одни толкают эти настроения потому, что деньги на этом делают. Если, например, не культивировать сверхценность кавычек, свисающих скобок и более точной передачи гарнитур, то чем будет отличаться дизайнерская студия от студента-сайтостроителя? Тем, что студент на@#$ никого не посылает? Так вот, а другие забесплатно толкают тот же... скажем вежливо, набор ценностей. За идею. Пионеры такие.
Не уловил мысли.
SV.>Это не полемика, а считаю я нужным вякнуть против. Прочитают немногие, но сила не за многими, а за умными.
Т.е. не за тобой?
PS: а на Nexus One сейчас разрешение 250DPI. Ты не представляешь, как там офигительно красиво выглядит нормальный типографский текст.
Здравствуйте, SV., Вы писали:
SV.>Вопрос в том, зачем вообще они этим занимаются.
Несглаженные символы — очень сильный хинтинг.
Очень сильный хинтинг — жесткая привязка к пикселям.
Жесткая привязка к пикселям — расползание при смене DPI.
Невозможность смены DPI — несглаженные символы.
Субпиксельное сглаживание — возможность выйти из этого круга и перейти к мониторам, на которых оно постепенно станет ненужно.
Здравствуйте, Cyberax, Вы писали:
C>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI.
150 DPI — это 15'' при 1920х1200 или 20'' при 2560х1600. Где вы такие мониторы берете?
Здравствуйте, Mamut, Вы писали:
YKU>>О, начинается... Чужеродные кавычки и исконно-потосконные лапки... Давайте еще пофлеймим о важности дефиса вместо тире(не путать с минусом!). M>Почему же, можно пофлеймить.
M> M>Это все же разные знаки с разной смысловой нагрузкой. И — да, с тире читать удобнее, чем с дефисом.
M>ЗЫ. В скришоте использованы все три тире.
кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее)
T>>Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева,
LP>Ты видимо имеешь ввиду MVC. Ну, так WPF не одинок.
Нет, тут имелось ввиду совсем другое. В WPF пользовательский интерфейс живет в двух параллельных иерархиях: логическое дерево (как он выглядит программно, то есть DOM) и визуальное дерево (наборы визуальных примитивов, с помощью которых контролы рисуются).
Если говорить про MVC, то в WPF используется более продвинутая его версия MVVM, которая опирается на мощный биндинг.
T>>возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке),
LP>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки
LP>JComboBox.setRenderer(ListCellRenderer renderer)
Сравни: <Button><ComboBox>...</ComboBox></Button>
LP>Кручение — непосредственной поддержки нет, но ИМХО делается.
T>>мощная система разделяемых и наследуемых свойст и событий,
LP>банальщина
Ну, сравнение было с WinForms, а не со Swing. Вообще, это круто, когда ты можешь сам определить новое свойство для некоторого контейнера, которое автоматически унаследуется дочерними элементами этого контейнера и изменит их поведение. Например, недавно потребовалось решить такую задачу: надо было сделать так, чтобы некоторые Expander'ы не могли быть одновременно открыты, то есть в один момент времени мог быть открыт только один экспандер и при открытии нового старый бы автоматически закрывался. Причем были и независимые экспандеры, которые могли быть открыты в любое время. Решена задача была через AttachedProperty "ExpanderGroupName" (по аналогии с GroupName у radion button), которое вешалось на любой узел в XAML и это свойство наследовалось всеми дочерними expander'ами данного узла. Причем в любом подузле можно переопределить ExpanderGroupName. В результате, работает все так, что в один момент времени может быть открыт только один expander с одинаковым ExpanderGroupName.
Здравствуйте, Resnick, Вы писали:
C>>Есть (и уже достаточно давно). Ты можешь рисовать компоненты элементов управления как хочешь: http://doc.trolltech.com/4.6/qstyle.html R>Это не аналог VisualBrush, а аналог стилей и тем.
Ну я же сказал, что любую часть сцены можно отрендерить в битмап. И потом что угодно с ним делать. Вот тебе и VisualBrush будет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
T>>>>Недостаточно для чего? Для решения указанной задачи этого хватает за глаза. Из оверхеда — одна строчка кода в сеттере поля ViewModel — вызыать "OnPropertyChanged". И никакой магии не надо. C>>>Нет. Тебе надо будет подписать метку на ВСЕ файлы в подкаталогах выбранного элемента. И при изменении выбранного элемента не забывать менять их. MK>>Какая-то фигня. В MVVM я бы просто сделал свойство Sum, get-аксессор которого подсчитывал нужную величину. C>Ещё хуже. Детали пользовательского интерфейса проносим в модель.
Путаешь domain-model и view-model. Я говорил о второй.
MK>>Добавив файл, при помощи события PropertyChanged оповестил бы интерфейс, что свойство Sum изменилось. Заранее отмечу, придирка что файл добавил бы кто-то иной без моего ведома не прокатывает, потому что, во-первых, это также можно решить одним оповещением, а во-вторых, врядли в этом случае меняется одна и та же коллекция. MK>>И у меня возник такой вопрос: а как в Trellis решается ситуация, когда я не желаю, чтобы интерфейс реагировал на изменения в коллекции? C>Можно игнорировать определённые изменения, но это считается очень плохим решением.
Ну, вот например, мне по бизнесу нужно произвести множество изменений в коллекции, зачем мне отображать промежуточные состояния пользователю?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
T>>>>Недостаточно для чего? Для решения указанной задачи этого хватает за глаза. Из оверхеда — одна строчка кода в сеттере поля ViewModel — вызыать "OnPropertyChanged". И никакой магии не надо. C>>>Нет. Тебе надо будет подписать метку на ВСЕ файлы в подкаталогах выбранного элемента. И при изменении выбранного элемента не забывать менять их. MK>>Какая-то фигня. В MVVM я бы просто сделал свойство Sum, get-аксессор которого подсчитывал нужную величину. C>Ещё хуже. Детали пользовательского интерфейса проносим в модель.
Судя по всему, ты незнаком с MVVM. Рекомендую ознакомиться.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, MxKazan, Вы писали:
I>\A>>меня больше интересуют не глюки вроде "не удалось нарисовать хитровывернутый контрол", а "зависает ни с того ни с сего" MK>>У нас проект разрабатывается на WPF уже полтора года. За это время "шаловливые ручки" залезли во многие возможности WPF и чего чего, а зависаний не было ни разу. А вот если ты подразумеваешь тормоза, то WPF безусловно достаточно требовательна.
I>При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна.
Где именно она быстрее? На отрисовке сложных сцен? Ну так и уточняй. А пока что обычные GUI-приложения (где обычно десяток-другой контролов) WinForms запускаются в 2-3 быстрее и окошки заметно быстрее открываются.
WPF в плане быстордействия обгоняет традиционный GDI пока только там, где много контролов и визуальных эффектов. Не уверен, что пора уже все обычные приложения украшать рюшечками эстетики ради, если за это мы поплатимся заметной разницей в скорости запуска приложения. Так что на сегодняшней реальности WPF — это вовсе не тул общего назначения.
Здравствуйте, dr.Chaos, Вы писали:
DC>Странное дело, у меня тоже mergetool на C# писанный кошмарно долго рисуется по RDP, хотя KDE-шный Kompare мгновенно.
Пару лет назад мы разработали свой протокол для шаринга приложений и пробовали при этом разные технологии для определения изменившихся областей экрана. Так вот, что интересно, хотя технология mirror driver, которую использует серверный компонент RDP и есть самая экономная в плане ресурсов сервера, но она же и самая неподходящая, если у гуиписателя руки не из того места растут. Т.е. надо перерисовать маленькую часть GUI, вместо этого современные программисты тупо делают refresh/invalidate всего и не парятся. Тоже самое при двойной буферизации. Поэтому сейчас, ввиду того, что интернет до сих пор не такой уж быстрый, а ресурсы современного компа ого-го, гораздо лучший результат дает технология тупого сканирования кадров с некоторой частотой, сравнения с предыдущими и кодировки только разницы.
Здравствуйте, MxMsk, Вы писали:
V>>Нужен аналог CSS, нужен доп. аттрибут аналогичный class="someCssClass" в HTML+CSS. Насколько я знаю, сейчас можно задать стиль только по типу элемента и его ID (x::Key), что есть статическое прибивание гвоздями. Нужен стиль, вот как меню на DHTML делаются? Активному элементу присваивается какой-нить class="menuSelected", и оно отображается не так, как остальные пункты. MM>Чем x:Key не аналог someCssClass?
В CSS у нас система координат из 4-х осей: элемент, его ID, класс и их взаимное расположение. Т.е., вот есть в HTML текстовые элементы: <H1>, <H2>, ... Cвязка Type+x:Key образуют всего лишь одну переменную, аналогично "элементу" в HTML. Не хватает хотя бы еще одной переменной, типа class (фиг с ним с ID, хотя с ним удобнее и выразительнее) и особенно не хватает декларативного описания взаимного расположения, эдакого шаблона для матча визуальных шаблонов, чтобы можно было описать декларативно:
element1.class1 element2 { /* тут описываем стиль element2 если он внутри element1 у которого class=class1 */}
element1, .class1, element2 element3.class3 { /* тут описываем стили сразу для 3-х меташаблонов */}
Для конкретного инстанса элемента его стиль собирается аддитивным образом из всех этих меташаблонов, которым соотвествует элемент с его классом и положением относительно других элементов с их классами. Мало того, само описание стиля может быть задано относительным образом, например, можно указать размер шрифта 150% от указанного в объемлющем стиле.
V>>Нужна система стилей, отвязанная от конкретных контролов, их типов и их ID, ибо слишком большая связанность получается. В принципе, все уже придумано в CSS. К тому же описывать стили в XML, в виде <Setter Property="" Value=""> — это чокнуться, очень плачевно. MM>А мне нравится
Можно попросить тебя изобразить сначала простой пример:
есть текстовые блоки на некоем визуальном представлении. Эти текстовые блоки бывают 3-х типов: обычные, цитирование и код. В каждом из блоков надо делать выделения. Эти выделения, в зависимости от текущего стиля, могут быть обозначены в виде рамки, другого цвета фона или повышенной жирности.
в CSS структуру стиля для этого можно описать примерно так:
И этот стиль будет дополнять стили остальных элементов, типа <H1>, <small>, <address> и т.д.
MM>Ну да, по настоящему динамическими WPF-ные стили сделать не удастся. Если ссылку на стиль можно сделать динамической, то вот наследование (атрибут BasedOn) таким образом задать нельзя. Если бы MS открыл возможность пересоздания стилей по желанию, когда всё дерево заново конструируется, проблема бы пропала. Но пока этого нет и не знаю, появится ли. Поэтому, собственно, приходится жертвовать некоторыми достоинствами наследования, и тем не менее ничто не мешает менять связку "контрол-стиль" в рантайме.
Понимаешь, контролов должно быть мало, а одновременно используемых для одного контрола стилей на одной форме — много. В итоге, для получения некоего разнообразия надо наследоваться от контролов без добавления какой-либо функциональности, только для того, чтобы отделить типы контролов друг от друга "по смыслу" (т.е. получить аналог element из HTML), а уже x:Key использовать как доп. координату, аналог class. И все-равно, без меташаблонов, описывающих взаимное расположение, ничего серьезного в виде стилей описать не получится.. так, по мелочи разве что.
Т.е. ситуация получилась странная — есть мега мощща возможностей, но ими совершенно невозможно пользоваться, эти возможности неуправляемы. Сегодня хрен ты чего адекватно опишешь ручками в XAML, если захочишь поработать над более-менее "богатым" стилем приложения, без Expression Blend будешь топтаться на месте. А полученное в ExpresionBlend будет слабопараметризуемо, в отличие от HTML, где я весьма оперативно отлаживаю стили CSS прямо из блокнота, не задевая структуры целевого HTML.
Ясное дело, что разработчики WPF попытались использовать одну и ту же технику как для описания структуры визуальных элементов, так и для параметризации значений готовой структуры, и на этом попались, ибо не фиг было на спичках экономить, если уж такого монстра ваяют.
Вот этот сценарий сегодня, когда поработал в VS, потом полез в ExpressionBlend, потом доработал код и отображение в VS, "поломались" стили, опять лезем в ExpressionBlend и так до бесконечности... Это такая, надо сказать, лажа... на самом высоком уровне.
Они же себе ставили целью отделить работу художников от работы программиста, а на самом деле получилось в десятки раз более жестко одно на другое завязанно, чем даже в HTML.
Здравствуйте, Silver_s, Вы писали:
S_>Если приведешь код на WPF который хотя бы не более чем в 2 раза медленнее чем WinForms GDI+, скажу огромное спасибо.
Легко (тут Window а не узерконтрол, ну да я надеюсь к этому ты не будешь придираться)
public partial class MainWindow : Window
{
private WriteableBitmap wb = new WriteableBitmap(300, 300, 96, 96, PixelFormats.Pbgra32, null);
public MainWindow()
{
InitializeComponent();
image.Source = wb;
image.MouseMove += new MouseEventHandler(image_MouseMove);
}
void image_MouseMove(object sender, MouseEventArgs e)
{
var p = e.GetPosition((IInputElement)sender);
wb.Lock();
var bmp = new System.Drawing.Bitmap(wb.PixelWidth, wb.PixelHeight,
wb.BackBufferStride,
System.Drawing.Imaging.PixelFormat.Format32bppPArgb,
wb.BackBuffer); // :Dvar g = System.Drawing.Graphics.FromImage(bmp);
g.Clear(System.Drawing.Color.White);
for (int i = 0; i < 900; i += 1000 / 200)
for (int j = 0; j < 900; j += 1000 / 200)
{
g.DrawRectangle(System.Drawing.Pens.Black, (int)p.X + i, (int)p.Y + j, 5, 5);
}
g.Dispose();
bmp.Dispose();
wb.AddDirtyRect(new Int32Rect(0, 0, 300, 300));
wb.Unlock();
}
}
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, x64, Вы писали:
x64>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать.
Пиши на HTMLayout
Здравствуйте, LaPerouse, Вы писали:
LP>>>JComboBox.setRenderer(ListCellRenderer renderer) T>>Сравни: <Button><ComboBox>...</ComboBox></Button>
LP>Для Swing тоже имеются сторонние библиотеки для xml-описания интерфейса. Но ими никто не пользуется
Кривые значит.
LP>А в чем преимущество наследования — в том, что expander-ы, не имеющие группу, наследуют от родителя какое-то определенное значение свойства ExpanderGroupName = "undefined" и их не надо прописывать в конкретном expander?
Да. Таким образом можно сразу всей иерархии контролов навесить свойство в одном месте. Тоже самое касается и событий.
Здравствуйте, Ikemefula, Вы писали:
RO>>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. I>>>И что еть в QT что перекрывает по возможностям WPF ? Можешь ответить внятно, без увиливаний ? C>>Удобное декларативное задание контролов (XAML отдыхает) и анимация. I>Покажи, что именно нельзя сдлать на WPF.
Там всё делается. В теории. Точно как и на WinForms.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ikemefula, Вы писали:
C>>>Стоит заметить, что твоим советам стоит следовать. Только выполнять их наоборот. I>>Без преувеличения можно сказать что WPF это уже устоявшаяся технология,а твой лаёут эт вечно подростковый Nextgen, которы будет таким и через 10 лет. Мало написать либы. C>HTMLayout существует дольше, чем WPF И установлен сейчас на бОльшем числе компьютеров, чем все программы с WPF, пожалуй.
Чушь. А время существования никого не интересует.
I>>Нужна поддержа со стороны IDE и много чего еще. C>Так там HTML+CSS. Любой редактор HTML в руки, и вперёд.
html это слишком мало. Любой редактор не сможет обеспечить например хотя бы тот же интеллисенс.
\A>>меня больше интересуют не глюки вроде "не удалось нарисовать хитровывернутый контрол", а "зависает ни с того ни с сего" MK>У нас проект разрабатывается на WPF уже полтора года. За это время "шаловливые ручки" залезли во многие возможности WPF и чего чего, а зависаний не было ни разу. А вот если ты подразумеваешь тормоза, то WPF безусловно достаточно требовательна.
При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна.
Здравствуйте, Cyberax, Вы писали:
I>>>>И что еть в QT что перекрывает по возможностям WPF ? Можешь ответить внятно, без увиливаний ? C>>>Удобное декларативное задание контролов (XAML отдыхает) и анимация. I>>Покажи, что именно нельзя сдлать на WPF. C>Там всё делается. В теории. Точно как и на WinForms.
Я правильно тебя понял, в QT, теоретически, делается все тоже самое, что и в WPF, но точно так же как и на WinForms, что означает QT работает ровно так же,через анус, как и winforms ?
LP>>>Для Swing тоже имеются сторонние библиотеки для xml-описания интерфейса. Но ими никто не пользуется I>>И это не с проста. Swing к этому подталкивает.
TBG>Винда вообще подталкивает иметь сторонние программки, но никто не утвержает, что это неспроста.
Представь себе, Микрософт не пичкает систему софтом, т.к. пользователи все разные.
TBG>Просто Swing способствует написанию библиотек, поскольку всё легко и доступно.
Я вынужден пользоваться софтом писаным на джаве и мне лично это сильно не нравится по ряду причин, кои проявляются буквально везде, тотально. Ущербный УИ, кривой лайеут, недо-мега-контролы, тормоза и какой то отстой по RDP, при чем канал у меня где то 6 мбит
Здравствуйте, Cyberax, Вы писали:
I>>>>Чушь. А время существования никого не интересует. C>>>Сам что-то заблеял про "подростковый nextgen". Это WPFу надо ещё из возраста CoolKids вырости. I>>Время существования никого не интересует. WPF уже поддерживается многими инструментами, а твой мега-продукт вобщем то ничем. C>Требование мега-инструментов для работы с продуктом — это вовсе не плюс.
Требования только у тебя в голове. Любой инструмент повышает производительность труда. WPF позволяет создавать инструменты для себя, вот и все.
I>>>>html это слишком мало. Любой редактор не сможет обеспечить например хотя бы тот же интеллисенс. C>>>Ну так кто мешает? Я вот пишу код для HTMLayout на Java, с IntelliSense'ом и прочими радостями. I>>Покажи это чудо. C>http://www.jetbrains.com/
C>Конкретно небольшая часть фич для HTML+CSS показана здесь:
Нужны фичи для HTMLLayout. Могу я в твоем html+css редакторе налепить например примитивов для векторной графики и ожидать, что в коде интеллисенс мне все это подскажет. Или же наоборот, в код налепить всякгого, а потом при редактировании html получать помощь в виде того же интеллисенса и разумеется все это при работе с примитивами
Здравствуйте, Cyberax, Вы писали:
C>>>В IDEA — да I>>Как в ней посмотреть это дело ? C>Скачай их WebIDE, скачай Sciter и пооткрывай примеры.
Все это у меня есть, но я не сильно представляю что мне надо сделать. Я привык к такому инструменту — кликнул мышом, сразу создаётся проект со всеми потрохами
Здравствуйте, Sheridan, Вы писали:
S>ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111111111111111111111111111111111111одинодинодинодинодинодинодинодинодинодинодинодинодинодин
Приятно удивлен информативностью твоего поста. Ожидал что ты просто поставишь смайлик...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Codechanger, Вы писали:
C>В принципе можно простой пример — реализация окна с отражением контента окна.Естественно, с градиентной прозрачностью, всеми делами. Хотелось бы видеть примерчик на qt. Как это реализуется на wpf, можно посмотреть по ссылке: C>здесь. Раздел Example: Create a Reflection. Там даны две возможных реализации — чистый код и чистый XAML. Ждем результатов от адептов qt/HTMLayout. Не забывайте, пожалуйста, указывать затраченное время.
Здравствуйте, Ikemefula, Вы писали:
I>>>А теперь, что бы все были в равных условиях, покажи решение на JS VB и Джава C>>Причём здесь JS, VB и Java? Это CSS — т.е. декларативное описание интерфейса. I>При том, что не надо ничего никуда портировать, все работает сразу и на ура.
Ты бредишь или как? HTMLayout — это способ использования CSS+HTML для описания интерфейса. ЕСТЕСТВЕННО, не надо ничего никуда портировать. Пример с reflection'ом работает вообще без задания даже одной строчки кода.
I>Более того, можно дать ссылку и на доку и на хорошую демку и на страничку с описанием всякой всячины, похожими проектами и тд и тд и тд,более того, в два-три клика все это опробовать.
Скачиваешь HTMLayoutSDK и смотришь примеры. Там прекрасно всё демонстрируется. Отсутствие одной комплексной демки — это да, недостаток.
Открытый API там тоже прекрасно задокументирован (он вообще там офигительно простой). Не знаю, ты может привык к монстроидальным API, в которых у каждой функции минимум по 20 параметров. В HTMLayout всё чрезвычайн просто.
Здравствуйте, Cyberax, Вы писали:
I>>>>А теперь, что бы все были в равных условиях, покажи решение на JS VB и Джава C>>>Причём здесь JS, VB и Java? Это CSS — т.е. декларативное описание интерфейса. I>>При том, что не надо ничего никуда портировать, все работает сразу и на ура. C>Ты бредишь или как? HTMLayout — это способ использования CSS+HTML для описания интерфейса. ЕСТЕСТВЕННО, не надо ничего никуда портировать. Пример с reflection'ом работает вообще без задания даже одной строчки кода.
Т.е. нужная либа подключится сама собой ? зачем же ты под линукс портировал, если ничего не надо портировать ?
C>Скачиваешь HTMLayoutSDK и смотришь примеры. Там прекрасно всё демонстрируется. Отсутствие одной комплексной демки — это да, недостаток.
Я уже посмотрел и не нашел ничего кроме одной крепкой либы. Ровно либа, до технологии как до небес.
C>Открытый API там тоже прекрасно задокументирован (он вообще там офигительно простой). Не знаю, ты может привык к монстроидальным API, в которых у каждой функции минимум по 20 параметров. В HTMLayout всё чрезвычайн просто.
Здравствуйте, Codechanger, Вы писали:
C>>Технология в HTMLayout — это HTML+CSS. Ничуть не менее сложная или менее продвинутая, чем тот же WPF. Просто HTML+CSS — это СТАНДАРТНАЯ технология, её не надо специально для HTMLayout учить. C>Тока енто. Надо указывать, что стандартная для веба. Это раз. Следовательно, имеет ограничения, характерные для веба.
Ничуть не "следовательно". HTMLayout — это НЕ "библиотека для web'а", она просто _использует_ стандарт HTML, чтобы не изобретать колесо.
C>Ну насчет байндингов так и не ответили.
Что именно отвечать-то? Я так и не понял. Это код в CSS, ему пофиг какие ты байндинги используешь.
Здравствуйте, Codechanger, Вы писали:
C>>Ааааааааааааааааааааааааааааааааааааааа! C>Ток вот на вопрос про биндинги Киберах так и не ответил...
Ну, пожалуйста, разъясните мне что за вопрос-то? Я уже от любопытства умираю.
Здравствуйте, squid, Вы писали:
C>>Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода. S>давай куб с отдельным видео из файла или камеры на каждой грани. как это сделано на WPF написал несколько выше, строчек 50 примерно. куб должен уметь крутиться в 3D, делать все по-честному.
Так я и знал, что кто-то про 3D заикнётся Тот 3D, который есть в WPF, ни на что кроме вращающегося кубика не пригоден.
Здравствуйте, Ikemefula, Вы писали:
C>>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж. C>>Скажем, как мне в таблице сделать удобное редактирование ячеек? Никак, так как угрёбищная система с editor'ами никуда не годиться. Так же, нельзя нормально делать композитные контролы и т.п. I>Ну что ты, swing это круто !!!
Уже нет HTMLayout круче.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx C>>>Недостаточно даже близко. T>>Недостаточно для чего? Для решения указанной задачи этого хватает за глаза. Из оверхеда — одна строчка кода в сеттере поля ViewModel — вызыать "OnPropertyChanged". И никакой магии не надо. C>Нет. Тебе надо будет подписать метку на ВСЕ файлы в подкаталогах выбранного элемента. И при изменении выбранного элемента не забывать менять их.
Какая-то фигня. В MVVM я бы просто сделал свойство Sum, get-аксессор которого подсчитывал нужную величину. Добавив файл, при помощи события PropertyChanged оповестил бы интерфейс, что свойство Sum изменилось. Заранее отмечу, придирка что файл добавил бы кто-то иной без моего ведома не прокатывает, потому что, во-первых, это также можно решить одним оповещением, а во-вторых, врядли в этом случае меняется одна и та же коллекция.
И у меня возник такой вопрос: а как в Trellis решается ситуация, когда я не желаю, чтобы интерфейс реагировал на изменения в коллекции?
Здравствуйте, MxKazan, Вы писали:
MK>Какая-то фигня. В MVVM я бы просто сделал свойство Sum, get-аксессор которого подсчитывал нужную величину. Добавив файл, при помощи события PropertyChanged оповестил бы интерфейс, что свойство Sum изменилось. Заранее отмечу, придирка что файл добавил бы кто-то иной без моего ведома не прокатывает, потому что, во-первых, это также можно решить одним оповещением, а во-вторых, врядли в этом случае меняется одна и та же коллекция.
Собственно я это и мел ввиду.
MK>И у меня возник такой вопрос: а как в Trellis решается ситуация, когда я не желаю, чтобы интерфейс реагировал на изменения в коллекции?
Мне вообще подобная магия не нравится, так как чуть шаг в сторону и она ломается. Чтобы починить — обычно начинаются пляски с бубном. Это я не про trellis а вообще про "магию".
Здравствуйте, mrTwister, Вы писали:
C>>В том-то и дело, что я могу с помощью реактивного программирования тривиально связывать бизнес-логику и интерфейс. T>Интерфейс сам посебе может иметь сложную интерфейсную логику, которая никак не относится к бизнес-логике и тут нет прямой связи бизнес-логики с интерфейсом. Вот именно такую интерфейсную логику и помещают во ViewModel.
Вот именно большую часть этой сложной логики и можно убрать с помощью реактивного программирования.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>Интерфейс сам посебе может иметь сложную интерфейсную логику, которая никак не относится к бизнес-логике и тут нет прямой связи бизнес-логики с интерфейсом. Вот именно такую интерфейсную логику и помещают во ViewModel. C>>>Вот именно большую часть этой сложной логики и можно убрать с помощью реактивного программирования. T>>Куда убрать? Вот простейший пример: при установки чекбокса надо дизейблить кнопку. Куда ты предлагаешь убрать эту логику и как её тестировать? C>Привязываешь свойство "disabled" кнопки к свойству "!selected" у чекбокса. Какие проблемы-то?
C>Тестировать как обычно — юнит-тестами.
Юнит тесты в подобной ситуации не очень помогут, к сожалению.Не видел я еще нормальных юнит тестов на UI(TestComplete в нос прошу не тыкать).
Однако то, что вынесено в модель, протестировать действительно можно. У меня в текущем проекте степень покрытия тестами WPF проектов > 50%.Фактически, неохвачена только часть, связанная с непосредственным отображением данных, т.е. XAML. Все остальное легко тестируется.
Здравствуйте, Cyberax, Вы писали:
C>Я уже приводил примеры огромных контор, которые строят на HTMLayout свой бизнес. Что касается остального — работаю над этим.
HTMLayout хорош с несколько других точек зрения — это в первую очередь независимость от других очень больших программных пакетов, типа WPF/.Net или QT. В принципе, другого вменяемого по размерам бинарника GUI тулза просто нет на сегодня.
И зря ты пытаешься спорить с WPF на их поле, преимущество HTMLayout совершенно в другом — факт использования его в многих очень известных программах тому подтверждение. Точно так же как отсутствие факта использования WPF хоть в какой-нить более-менее известной программе, кроме беты MS VS 2010.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Без точности не будет читабельности. Как отрисовать подряд несколько букв шириной 2,4 пикселя?
Как их читать затем?
Зачем переставлять местами причину и следствие? Уже вроде недавно об этом же поговорили, а ты все за свое...
Надо исходить из того, что есть, а есть около 100 DPI на современных мониторах, как бы тебе не хотелось иного. Для предпросмотра в системах верстки можно рендерить без хинтинга, чтобы убедиться, что все на месте, но для чтения — обязательно хинтинг со всеми искажениями в пользу позиционирования по пикселям, иначе зрению хана.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Но кто мне скажет, что нижнее изображение читается лучше, или выглядит четче, или точнее передает форму букв шрифта, в того я первый брошу камень.
по мне так оно в разы круче и удобнее выглядит... третья строчка. а остальные все равно нигде реально на экране не будут, мелкие слишком. короче ты фигней страдаешь, выдумывая пример где технология выигрывает.
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>Плохо настроены, надо полагать. FreeType-то один на всех. F>> А почему Gtk это делает нормально? RO>Хорошо настроена, надо полагать.
Т.е. реально использовать Qt нельзя.
Здравствуйте, squid, Вы писали:
RO>>Но кто мне скажет, что нижнее изображение читается лучше, или выглядит четче, или точнее передает форму букв шрифта, в того я первый брошу камень.
S>по мне так оно в разы круче и удобнее выглядит... третья строчка. а остальные все равно нигде реально на экране не будут, мелкие слишком. короче ты фигней страдаешь, выдумывая пример где технология выигрывает.
Так оно же на четверть длиннее. FreeType на такой длине будет выглядеть еще лучше.
FreeType:
ClearType:
FreeType, третья строчка, 10,3 пикселя:
Хотя здесь сила привычки наверняка перевешивает всё остальное. Мне, например, неприятно, когда у буквы s резко пропадают все засечки, T превращается в Г, v и w непропорционально плющатся (что еще ужаснее от чрезмерно тонкого штриха), а кому-то подавай буквы повышенной квадратности, и типографические достоинства побоку.
Насчет строчек особо мелких размеров, можно подумать, что масштабирование уже отменили, и никогда не нужно вглядеться в слово при маленьком масштабе.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Roman Odaisky, я писали:
V>>>FreeType на малых разрешениях сливает TrueType, а в больших уже не принципиально.
RO>Картинку в студию так и не предоставили. Что ж, я сам сделал скриншот из MSIE. Сравним.
RO>FreeType: RO>
RO>ClearType: RO>
RO>Размеры всё-таки разные, несмотря на то, что заданы они в пикселях. Это можно понять, настройки хинтинга разные. Для ClearType размер текста 8 и 8,5 пикселей — одно и то же. Ладно, разговор о точности позиционирования отложим на потом. Но кто мне скажет, что нижнее изображение читается лучше, или выглядит четче, или точнее передает форму букв шрифта, в того я первый брошу камень.
Надо правильным IE пользоваться
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Y>>>А почему не на HTMLayout или QT? C>>"У них один фатальный недостаток" (c) не помню. Y>Ну если Microsoft вызывает такое желание поязвить, то возьми другую компанию с большим и долгоиграющим продуктом.
Нокия и Symbian?
C>>А пишут они его на С++ из-за того, что: C>>1) Куча legacy-кода. C>>2) У них достаточно ресурсов на это. Y>Ага. Теперь осталось сделать один маленький шажочек и понять что это-же относиться не только к языку, но и к платформе/библиотекам. Тогда ты ответишь на вопрос vdimas.
Для WinForms не может быть пока особо много legacy. Вопрос с ресурсами — тоже не проходит, так как особой разницы между WinForms и WPF нет для конечного пользователя.
Здравствуйте, vdimas, Вы писали:
I>>Овнердров этот более-менее хорошо сделан в DevExpress.
V>Ммм... как бы это спросить помягче... Ты давно в отрасли?
Думаю что дОльше тебя.
V>Давай эту тему тупо закроем. Я понимаю, что ты, возможно, столкнулся с owner draw, но не потрудился разобраться, да и твоему поколению наверно уже и не зачем. Всё, забыли про owner draw, ему уже 30 лет скоро и пора его на помойку.
Какя разница, сколько ему лет ? Он никогда не был серьезно проработан. Скудные возможности, сложный интерфейс, обилие багов — это было всегда.
I>>Вообще говоря она просто использует GDI и на нём не построена. V>Вообще говоря, плохо у тебя получается упражняться в терминах, и не понятна цель подобного времяпрепровождения.
Построена на GDI это например про GDI+.
А окошки всякие, винформс только используют GDI. Тут не надо терминов знать. см. ниже.
V>По нашему вопросу — оконная система виндов не может без GDI, невозможно подсунуть ей "нечто" вместо него, там все вшито намертво с
односторонней зависимостью. А когда одна программная компонента использует таким неотъемлимым способом другую, говорят, что первая на второй построена (основана).
Правильно так — отрисковка в оконной системе виндов построена на GDI. Но сама оконная система виндов не сводится к отрисовке и потому в корне неверно утверждать что она построена на GDI.
V>Раздражает просто, когда ты на собеседника время тратишь, обдумывая его фолианты, а он явно читает по-диагонали и не трудится напрягать кое-какой важный орган, что профанирует любое обсуждение до уровня бодания бичей в общественном месте.
Вот канальи !
V>Когда-то, уважаемый Sinclair выдал нам несколько правил этики профессионала, мне очень импонирует: http://rsdn.ru/forum/job/24554.1.aspx
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, yuriylsh, Вы писали:
Y>>Не очень понял условия задачи. Как в твоем примере с css будет разруливаться какое выделение применять (рамка, цвет, жирность)? Может ты изобразишь сначала свой пример? Пока по аналогии на WPF можно описать примерно так :
Y>>
V>А как мне тогда задать отличие текста <H1> от <H2>?
А для чего тебе их отличать? Стиль же не затирает базовый. Применишь его к нужному элементу и стиль перекроет только те свойства, setter-ы которых в нем заданы.
Здравствуйте, MxMsk, Вы писали:
V>>Понимаешь, контролов должно быть мало, а одновременно используемых для одного контрола стилей на одной форме — много. В итоге, для получения некоего разнообразия надо наследоваться от контролов без добавления какой-либо функциональности, только для того, чтобы отделить типы контролов друг от друга "по смыслу" (т.е. получить аналог element из HTML), а уже x:Key использовать как доп. координату, аналог class. И все-равно, без меташаблонов, описывающих взаимное расположение, ничего серьезного в виде стилей описать не получится.. так, по мелочи разве что. MM>Да как-то дело привычки, по-моему. Никогда всерьез не занимался Вебом, поэтому не страдаю без чего-то подобного CSS. По мне так те же яйца только в профиль. Нет некоторых фич, но не так уж и часто они оказываются нужны.
Да, вопрос смены стиля встает нечасто. Но вот у меня иногда встает (заказчики хотят ребрендить нашу разработку, т.е. снабжать своим лого и стилем), и я пока просто присматриваюсь в этом плане.
V>>Они же себе ставили целью отделить работу художников от работы программиста, а на самом деле получилось в десятки раз более жестко одно на другое завязанно, чем даже в HTML. MM>Пока ты будешь рассматривать XAML сквозь призму HTML, тебе будут видится одни проблемы.
HTML — это охренительный набор практик в области декларативного UI, выкидывать эти практики и возвращаться в пещеры как-то жалко.
Здравствуйте, c-smile, Вы писали:
CS>А как в runtime разкоментировать скажем <StackPanel>?
Легко направляем всё в ListBox по горизонтали:
var factory = new FrameworkElementFactory(typeof(StackPanel));
factory.SetValue(StackPanel.OrientationProperty, Orientation.Horizontal);
lb.ItemsPanel = new ItemsPanelTemplate(factory);
А можно возложить всё на XAML, переключая ресурсы.
А можно управлять созданной панелью, через VisualTreeHelper.
А можно сделать мега-панель, которая вообще будет настраиваться свойствами (и binding прикрутим, если потребуется).
CS>(Кто-то тут сказал что с XAML удобно в text editor работать. Месье знает толк в извращениях ...)
Никакого извращения. Более того, это ничем не отличается от редактирования HTML. Ну, т.е. вообще ничем.
Здравствуйте, Ikemefula, Вы писали:
I>Нет, речь идет о "Windows provides three main categories of objects: user interface, graphics device interface (GDI), and kernel."
Ну и? Первый из этих компонентов построен на двух последующих, с чем ты споришь?
Здравствуйте, dr.Chaos, Вы писали:
DC>Меня наоборот коробит от таких шрифтов, потому я просто поставил себе dpi 120 и средний хинтинг и глаза не устают и читать приятно.
Кстати, если речь шла о линухах (я не понял вначале о контексте), то там хинтинг не так чтобы сильно спасает и далеко не все шрифты. Особенно если хинтинг на максимуме, то он спасает лишь буквально несколько шрифтов, в остальных — лажа. В продолжение этого разговора: http://www.rsdn.ru/forum/unix/3721193.1.aspx
Мне только непонятно одно, почему он до сих пор не влился в команду какого-нить проекта фонт-сервера и не сделал им нормальный рендеринг, наконец.
А то в сети полно причитаний, типа "ну вот в линухах уже полно всякой ненужной рюшечно-кружавчатой херни, а нормального рендеринга шрифтов как не было, так и не ожидается".
Здравствуйте, Roman Odaisky, Вы писали:
RO>Берешь любимую читалку PDF, открываешь многостраничный PDF, сильно уменьшаешь масштаб, чтобы увидеть все страницы сразу. Можно подумать, что читабельность заголовков помешает.
Сколько раз средний юзер это делает? Это даже не смешно.
SV.>>Что касается знатоков нереальных программ, то надо ли из-за них ставить раком всех остальных?
RO>И твое внимание я тоже обращу на то, что постановка задачи звучала именно так — «FreeType на малых разрешениях сливает TrueType» (очевидно, имелось в виду ClearType). На разрешениях побольше FreeType тоже превосходит ClearType.
RO>Тем более, это же юникс-вей, хочется — поставь сильный хинтинг, хочется — задай особые настройки хинтинга для моноширинных шрифтов определенного размера. Но это уже издевательство над всеми достижениями типографики за последние 500 лет.
А я не про FreeType, и уж тем более не про юникс-вей. А про (в том числе вашу) безудержную пропаганду субпиксельного рендеринга для улучшения типографики (чтоб ее скрутило, проклятую).
Субпиксельный рендеринг как способ отобразить на мониторе шрифт похожим на тот же шрифт, но напечатанный в типографии — маргарин вместо масла, безвкусный, дешевый и вредный для здоровья заменитель. Хотя преподносится некоторыми как передний край прогресса. Преподносится, кстати, теми же людьми, которые рисуют лапки вместо старых добрых "". Что касается переднего края прогресса — им будет монитор, dpi которого достаточно, чтобы без жалких уловок рисовать что угодно и как угодно, в том числе шрифты малым кеглем и изысканными гарнитурами.
Интересно то, что одни толкают эти настроения потому, что деньги на этом делают. Если, например, не культивировать сверхценность кавычек, свисающих скобок и более точной передачи гарнитур, то чем будет отличаться дизайнерская студия от студента-сайтостроителя? Тем, что студент на@#$ никого не посылает? Так вот, а другие забесплатно толкают тот же... скажем вежливо, набор ценностей. За идею. Пионеры такие.
Это не полемика, а считаю я нужным вякнуть против. Прочитают немногие, но сила не за многими, а за умными.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, Cyberax, Вы писали:
C>>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI.
SV.>А маки что — при отрисовке шрифтов не прибегают к этому субпиксельному жульничеству? Прибегают, как и все остальные. Куда ж им деваться, когда ваших крутых 150 dpi по-прежнему МАЛО для честной отрисовки. Вот будет больше в 4 раза, тогда перестанут. Вопрос в том, зачем вообще они этим занимаются. С макинтошниками все давно понятно, но ведь и те, кто массового потребителя обслуживает, сами соблязнулись и его... туда же.
Зачем они занимаются субпискельным сглаживанием? Наверно, чтобы пользовтелем было удобнее и приятнее читать, я не особый эстет, но сглаженные шрифты мне нравятся куда больше.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Субпиксельное сглаживание — возможность выйти из этого круга и перейти к мониторам, на которых оно постепенно станет ненужно.
НЕТ мониторов, которые могли бы, задействуя целое число исключительно черных пикселей, выводить исключительно черный текст, похожий на хороший типографский. Когда они появятся, тогда и без вас с McSeem'ом как-нибудь улучшат типографику. То, что мониторы не появляются потому, что софтверные компании ваши идеи не внедряли (тот самый якобы круг), а не потому, что попросту НЕТ подходящей технологии, это ложь и провокация.
Здравствуйте, Mamut, Вы писали:
M>>>
A>>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее)
M>Поому что скриншот из макоси в других ОСях, увы, будет выглядеть хуже.
M>>Здравствуйте, Константин Б., Вы писали: КБ>>>Здравствуйте, Mamut, Вы писали: A>>>>>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее) M>>>>Поому что скриншот из макоси в других ОСях, увы, будет выглядеть хуже. КБ>>>В Макоси свой супер-пупер рендерер PNG ? M>>разрешение выше
КБ>Ну закачал картинку на телефон с 250 DPI. Лучше не стало.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Ikemefula, Вы писали:
MK>>>А вот если ты подразумеваешь тормоза, то WPF безусловно достаточно требовательна. I>>При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна. S_> Может в WPF есть специальная команда выключения тормозов? А то у меня наоборот получается WPF в разы медленнее чем GDI+. S_> Нарисуй 200x200 примитивов через drawingContext.DrawRectangle, GDI+ в разы быстрее, Direct3D/2D еще в разы быстрее. S_>Или вращающийся кубик в WPF бысрее чем в GDI+, только зачем один кубик нужен?
О, ну да, 200x200 прямоугольничков в разы нужнее вращающегося кубика
Здравствуйте, x64, Вы писали:
x64>Я пока даже не уверен вообще надо ли оно мне. Отговорите, а?
Так если то, чем ты сейчас пользуешься, тебя удовлетворяет, то ничего и не надо делать.
Есть тут у нас одна фирма, сайт которой постоянно поднимает мне настроение. Например, вот это: http://it-dimension.com/service/new-ms-technologies/. Майкрософт очень уж любит стратегию, которую Джоэл называет «Fire and Motion». Если ты не видишь преимуществ от перехода, то зачем участвовать в крысиных бегах?
еще четыре-пять лет, пока давление со стороны производителей высококачественных мониторов не вынудит микрософт таки нанять Максима или разработать растеризатор самостоятельно». То же самое кто-то на RSDN говорил касательно отрисовки шрифтов. Сама мысль о том, что можно просто перейти на (свободно распространяемые!) библиотеки AGG и FreeType кажется какой-то чуждой, хотя эти продукты на порядок лучше того, что используют в MS.
Насчет преимуществ: я, естественно, не использовал ни то, ни другое, но, насколько я знаю, WPF — единственная виндовая технология, которая правильно отрисовывает мой простенький типографический тест: http://qwertty.com/tmp/ScreenTypographyTest.html.
Ты не мог бы сравнить со Swing?
Я попробую сделать это по твоему тексту, хотя понятия не имею о том, что такое WPF.
T>Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева,
Ты видимо имеешь ввиду MVC. Ну, так WPF не одинок.
T>возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке),
За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки
JComboBox.setRenderer(ListCellRenderer renderer)
Кручение — непосредственной поддержки нет, но ИМХО делается.
T>мощная система разделяемых и наследуемых свойст и событий,
банальщина
T>event tunneling и event bubbling, мощнейшая система биндинга, позволяющая вообще отказаться от code-behind и полностью разнести логику пользовательского интерфейса с его внешним видом,
Имеются сторонние библиотеки для биндинга — jgoodies binding. Но, конечно, будет не столь круто.
T>система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно,
Swing look-and-feel
T>очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании, очень сильная способность (круче, чем в HTML) создавать интерфейс со сложным и гибким layout'ом без привязки к пикселям и автоматически красиво подстраивающийся под любые размеры рабочей области, аппаратное ускорение.
Swing имеет богатый набор layout-ов.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, mrTwister, Вы писали:
RO>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. T>>Что из этого есть в Qt?
RO>Так и знал — стоит написать что-нибудь по делу (см. первое сообщение выше), так тишина, а как только пощекотать чье-нибудь ЧСВ, так сразу же будет ответ, и не один .
В первом сообщении нет ни слова про Qt, а вопрос исключительно про WinForms и WPF, так что непонятно, к чему ты приплел Qt.
RO>Отвечая на вопрос, есть всё. WolfenQt видел?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Всё правильно, только опечатка, вместо WPF должно было быть Qt.
а по глюкам с qt оно сравнимо?
я просто c qt дела-то имею, а с wpf [пока] нет.
Здравствуйте, x64, Вы писали:
x64>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать.
Это декларативное программирование + вагон оверхеда в стиле мало напоминающе классику оконного програмирования по вындоус, в которую укладываются винформс.
> Т.е. вообще как-то странно получается, вроде занимаемся визуальным программированием, но при этом по-прежнему приходится ковырятся в каком-то (при чём незнакомом) языке.
И если тебе больше 30, то повод задуматься.
>И возникает закономерный вопрос — а есть ли в этом XAML что-нибудь, что может заставить обычного шароварщика, скажем, писать свой UI именно под WPF?
Есть, ибо многие вещи в UI на винформc нереализуемы в принципе если принять во внимание хотя бы минимальные ограничения по перформансу.
>Особенно учитывая, что софт какой-нибудь системный больше и не требует никаких особых красивостей. Может быть там какие-то контролы есть новые на замену обычным системным? Что там такого есть, ради чего стоит таки потрахаться как следует с WPF-дизайнером и этим грёбанным XAML? Может хоть ссылочку дадите для начинающих в WPF? Особенно для тех, кто на него с WinForms переходит. Я пока даже не уверен вообще надо ли оно мне. Отговорите, а?
погугли по MVVM, хватает материала. Или, например, открой Codeplex и посмотри там каких нить проектов. Уверен, если религия не стане на пути, найдешь все объяснения.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, x64, Вы писали:
x64>>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. C>Пиши на HTMLayout
Здравствуйте, Roman Odaisky, Вы писали:
T>>Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева, возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке), мощная система разделяемых и наследуемых свойст и событий, event tunneling и event bubbling, мощнейшая система биндинга, позволяющая вообще отказаться от code-behind и полностью разнести логику пользовательского интерфейса с его внешним видом, система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно, очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании, очень сильная способность (круче, чем в HTML) создавать интерфейс со сложным и гибким layout'ом без привязки к пикселям и автоматически красиво подстраивающийся под любые размеры рабочей области, аппаратное ускорение.
RO>Всё правильно, только опечатка, вместо WPF должно было быть Qt.
И что еть в QT что перекрывает по возможностям WPF ? Можешь ответить внятно, без увиливаний ?
Здравствуйте, Ikemefula, Вы писали:
x64>>>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. C>>Пиши на HTMLayout I>Это из тех советов, которым следовать не стоит.
нет, почему, просто это у тебя отторжение начинается от рекламы htmlayout где ни попадя. но это уже вопрос к авторам — действительно ли они решили всех достать
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, x64, Вы писали:
x64>>Мда. Похоже, что мне ничего этого не нужно. T>Ты знаешь, я тоже так думал, пока не начал этим пользоваться
T>ИМХО, у WPF главная проблема — это высокий порог вхождения.
Не у WPF, а у декларатвного и функционального программирования вообще.
> Разница в сложности между WinForms и WPF просто огромная. Ситуация осложняется всё еще сыроватостью технологии и отсутствием наработанных и проверенных паттернов. Даже у идеологов нет пока единого мнения, как кошерно делать интерфейс на WPF, использовать ли MVVM и как разделить обязанности между View и ViewModel. Короче, есть над чем голову поломать. У WinForms главное преимущество — это то, что там все просто, понятно, граблей минимум и они давно известны.
Винформс это вагон граблей и отсутствие методов решения. Например Ownerdraw есть сплошная проблема из за отсутсвия мало-мальского механизма отрисовки.
Здравствуйте, LaPerouse, Вы писали:
LP>Ты видимо имеешь ввиду MVC. Ну, так WPF не одинок.
MVVM а не то что ты указал.
T>>возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке),
LP>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки
И получится откровенное говно.
LP>JComboBox.setRenderer(ListCellRenderer renderer)
LP>Кручение — непосредственной поддержки нет, но ИМХО делается.
Попробуй повторить на 100 процентов поведение какого сложного контрола. Если получится, можешь записываться в конкурент WPF
T>>мощная система разделяемых и наследуемых свойст и событий,
LP>банальщина
Ога, ога
LP>Имеются сторонние библиотеки для биндинга — jgoodies binding. Но, конечно, будет не столь круто.
конечно не будет круто, одна библиотека для УИ, другая для бинднга — такое мало кому в голову придет
T>>система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно,
LP>Swing look-and-feel
Открой это чудо в RDP и убедись что это тупое, тормозное говно
T>>очень мощный и сильно расширяемый XAML, позволяющий производить сложные манипуляции с интерфейсом с помощью текстового редактора и избежать таким образом тонны кликов мышью и мата при мержевании, очень сильная способность (круче, чем в HTML) создавать интерфейс со сложным и гибким layout'ом без привязки к пикселям и автоматически красиво подстраивающийся под любые размеры рабочей области, аппаратное ускорение.
LP>Swing имеет богатый набор layout-ов.
И который до сих пор не нашел внятного применения. Сейчас на WPF(/E) больше функционала чем с твоем свингом за все времена.
Здравствуйте, Ikemefula, Вы писали:
RO>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. I>И что еть в QT что перекрывает по возможностям WPF ? Можешь ответить внятно, без увиливаний ?
Удобное декларативное задание контролов (XAML отдыхает) и анимация.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. A>а по глюкам с qt оно сравнимо? A>я просто c qt дела-то имею, а с wpf [пока] нет.
глюки есть. Тем не менее, глядя в демки, qt до wpf как до луны пешком. QT хорошо конкурирует с Winforms&GDI+
Здравствуйте, Antikrot, Вы писали:
x64>>>>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. C>>>Пиши на HTMLayout I>>Это из тех советов, которым следовать не стоит. A>нет, почему, просто это у тебя отторжение начинается от рекламы htmlayout где ни попадя. но это уже вопрос к авторам — действительно ли они решили всех достать
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, LaPerouse, Вы писали:
T>>>Мощь WPF проявляется на сложном интерфейсе. Эта сила заключается в следующих аспектах: разделение визуального и логического дерева,
LP>>Ты видимо имеешь ввиду MVC. Ну, так WPF не одинок.
T>Нет, тут имелось ввиду совсем другое. В WPF пользовательский интерфейс живет в двух параллельных иерархиях: логическое дерево (как он выглядит программно, то есть DOM) и визуальное дерево (наборы визуальных примитивов, с помощью которых контролы рисуются).
T>Если говорить про MVC, то в WPF используется более продвинутая его версия MVVM, которая опирается на мощный биндинг.
T>>>возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке),
LP>>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки
LP>>JComboBox.setRenderer(ListCellRenderer renderer) T>Сравни: <Button><ComboBox>...</ComboBox></Button>
Для Swing тоже имеются сторонние библиотеки для xml-описания интерфейса. Но ими никто не пользуется
LP>>Кручение — непосредственной поддержки нет, но ИМХО делается. T>>>мощная система разделяемых и наследуемых свойст и событий, LP>>банальщина
T>Например, недавно потребовалось решить такую задачу: надо было сделать так, чтобы некоторые Expander'ы не могли быть одновременно открыты, то есть в один момент времени мог быть открыт только один экспандер и при открытии нового старый бы автоматически закрывался. Причем были и независимые экспандеры, которые могли быть открыты в любое время. Решена задача была через AttachedProperty "ExpanderGroupName" (по аналогии с GroupName у radion button), которое вешалось на любой узел в XAML и это свойство наследовалось всеми дочерними expander'ами данного узла. Причем в любом подузле можно переопределить ExpanderGroupName. В результате, работает все так, что в один момент времени может быть открыт только один expander с одинаковым ExpanderGroupName.
А в чем преимущество наследования — в том, что expander-ы, не имеющие группу, наследуют от родителя какое-то определенное значение свойства ExpanderGroupName = "undefined" и их не надо прописывать в конкретном expander?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ikemefula, Вы писали:
RO>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. I>>И что еть в QT что перекрывает по возможностям WPF ? Можешь ответить внятно, без увиливаний ? C>Удобное декларативное задание контролов (XAML отдыхает) и анимация.
Здравствуйте, Ikemefula, Вы писали:
RO>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. A>>а по глюкам с qt оно сравнимо? A>>я просто c qt дела-то имею, а с wpf [пока] нет. I>глюки есть. Тем не менее, глядя в демки, qt до wpf как до луны пешком. QT хорошо конкурирует с Winforms&GDI+
меня больше интересуют не глюки вроде "не удалось нарисовать хитровывернутый контрол", а "зависает ни с того ни с сего"
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Ikemefula, Вы писали:
RO>>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. A>>>а по глюкам с qt оно сравнимо? A>>>я просто c qt дела-то имею, а с wpf [пока] нет. I>>глюки есть. Тем не менее, глядя в демки, qt до wpf как до луны пешком. QT хорошо конкурирует с Winforms&GDI+ A>меня больше интересуют не глюки вроде "не удалось нарисовать хитровывернутый контрол", а "зависает ни с того ни с сего"
Это как раз про GDI+. Тут куда ни ткни то возможно зависание или креш. Как оно работает, мн действительно оень интерено
Здравствуйте, Ikemefula, Вы писали:
C>>Стоит заметить, что твоим советам стоит следовать. Только выполнять их наоборот. I>Без преувеличения можно сказать что WPF это уже устоявшаяся технология,а твой лаёут эт вечно подростковый Nextgen, которы будет таким и через 10 лет. Мало написать либы.
HTMLayout существует дольше, чем WPF И установлен сейчас на бОльшем числе компьютеров, чем все программы с WPF, пожалуй.
I>Нужна поддержа со стороны IDE и много чего еще.
Так там HTML+CSS. Любой редактор HTML в руки, и вперёд.
Здравствуйте, Ikemefula, Вы писали:
C>>HTMLayout существует дольше, чем WPF И установлен сейчас на бОльшем числе компьютеров, чем все программы с WPF, пожалуй. I>Чушь. А время существования никого не интересует.
Сам что-то заблеял про "подростковый nextgen". Это WPFу надо ещё из возраста CoolKids вырости.
I>>>Нужна поддержа со стороны IDE и много чего еще. C>>Так там HTML+CSS. Любой редактор HTML в руки, и вперёд. I>html это слишком мало. Любой редактор не сможет обеспечить например хотя бы тот же интеллисенс.
Ну так кто мешает? Я вот пишу код для HTMLayout на Java, с IntelliSense'ом и прочими радостями.
А интерфейс — на HTML+CSS, как и надо. Кстати, там тоже IntelliSense с рефакторингом работает — у меня же не текстовый редактор, а нормальная IDE.
Здравствуйте, Ikemefula, Вы писали:
C>>Сам что-то заблеял про "подростковый nextgen". Это WPFу надо ещё из возраста CoolKids вырости.
I>Время существования никого не интересует. WPF уже поддерживается многими инструментами, а твой мега-продукт вобщем то ничем.
Здравствуйте, Ikemefula, Вы писали:
I>>>Чушь. А время существования никого не интересует. C>>Сам что-то заблеял про "подростковый nextgen". Это WPFу надо ещё из возраста CoolKids вырости. I>Время существования никого не интересует. WPF уже поддерживается многими инструментами, а твой мега-продукт вобщем то ничем.
Требование мега-инструментов для работы с продуктом — это вовсе не плюс.
I>>>html это слишком мало. Любой редактор не сможет обеспечить например хотя бы тот же интеллисенс. C>>Ну так кто мешает? Я вот пишу код для HTMLayout на Java, с IntelliSense'ом и прочими радостями. I>Покажи это чудо. http://www.jetbrains.com/
Конкретно небольшая часть фич для HTML+CSS показана здесь: http://www.jetbrains.com/webide/features/index.html#HTML_CSS
C>>А интерфейс — на HTML+CSS, как и надо. Кстати, там тоже IntelliSense с рефакторингом работает — у меня же не текстовый редактор, а нормальная IDE. I>Т.е. уже не любой редактор хтпл а таки нормальная иде ? Т.е. ты пургу гнал ?
Не, ну ты решай — IntelliSense нужен или нет? Без него вполне можно работать — так как обычный HTML, однако. Можно его прямо в браузере смотреть.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ikemefula, Вы писали:
RO>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. I>>И что еть в QT что перекрывает по возможностям WPF ? Можешь ответить внятно, без увиливаний ? C>Удобное декларативное задание контролов (XAML отдыхает)
Во-первых, это еще вопрос, что удобнее. Мне синтаксис Qt не показался очень удобным. И насколько он расширяем? Могу ли я писать свои Markup Extension'ы, конверторы и т.д.? Могу ли я его использовать для создания произвольных (своих собственных) объектов?
C>и анимация.
И в чем именно Qt-шная анимация превосходит WPF-ную?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, LaPerouse, Вы писали:
LP>>>>JComboBox.setRenderer(ListCellRenderer renderer) T>>>Сравни: <Button><ComboBox>...</ComboBox></Button>
LP>>Для Swing тоже имеются сторонние библиотеки для xml-описания интерфейса. Но ими никто не пользуется T>Кривые значит.
Не в кривости дело. Подобные вещи реально применимы только в том случае, когда являются стандартом (как xaml). В противном случае проблем можно отгрести.
LP>>А в чем преимущество наследования — в том, что expander-ы, не имеющие группу, наследуют от родителя какое-то определенное значение свойства ExpanderGroupName = "undefined" и их не надо прописывать в конкретном expander?
T>Да. Таким образом можно сразу всей иерархии контролов навесить свойство в одном месте. Тоже самое касается и событий.
Отношение контейнер-элемент — один из возможных способов "навешивания свойств в одном месте". java-библиотеки тоже часто используют такой подход. К примеру, Info-node docking framework позволяет дочерним окнам наследовать свойства родительских окон.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, mrTwister, Вы писали:
T>Во-первых, это еще вопрос, что удобнее. Мне синтаксис Qt не показался очень удобным. И насколько он расширяем? Могу ли я писать свои Markup Extension'ы, конверторы и т.д.? Могу ли я его использовать для создания произвольных (своих собственных) объектов?
Не просто неудобным. Это — убожество, которым способны наслаждаться лишь те, кто принципиально воротит нос от всего Микрософтского.
Вообще выражение присваивания через двоеточие, на мой взгляд, не самая читабельная конструкция. Обычное равно куда как нагляднее.
Здравствуйте, Ikemefula, Вы писали:
LP>>Для Swing тоже имеются сторонние библиотеки для xml-описания интерфейса. Но ими никто не пользуется I>И это не с проста. Swing к этому подталкивает.
Винда вообще подталкивает иметь сторонние программки, но никто не утвержает, что это неспроста. Просто Swing способствует написанию библиотек, поскольку всё легко и доступно.
Здравствуйте, Ikemefula, Вы писали:
LP>>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки I>И получится откровенное говно.
Получится то, что необходимо. Если необходимо.
LP>>Кручение — непосредственной поддержки нет, но ИМХО делается. I>Попробуй повторить на 100 процентов поведение какого сложного контрола. Если получится, можешь записываться в конкурент WPF
Будет нужно — будет повторено. Пока какое-то бессмысленное действие вряд ли кто соберётся повторять.
LP>>Имеются сторонние библиотеки для биндинга — jgoodies binding. Но, конечно, будет не столь круто. I>конечно не будет круто, одна библиотека для УИ, другая для бинднга — такое мало кому в голову придет
Разделяй и властвуй. Ничего страшного нет в разных библиотеках. Используется только то, что в данный момент нужно.
T>>>система стилей, позволяющая кастомизировать (полностью поменять) внешний вид и визуальные эффекты чего угодно, LP>>Swing look-and-feel I>Открой это чудо в RDP и убедись что это тупое, тормозное говно
Открыл. Хорошо работает. Или для достижения эффекта мне это надо смотреть на саморучно спаянном модеме со скоростью 5-7 байт/с?
LP>>Swing имеет богатый набор layout-ов. I>И который до сих пор не нашел внятного применения. Сейчас на WPF(/E) больше функционала чем с твоем свингом за все времена.
Если набор layout'ов не нашёл внятного применения, то мы до сих пор при свечках читаем. Изучил бы что ли вопрос.
Здравствуйте, Ikemefula, Вы писали:
LP>>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки I>И получится откровенное говно.
Ты пробовал? Или для троллинга пробовать необязательно?
LP>>Swing look-and-feel I>Открой это чудо в RDP и убедись что это тупое, тормозное говно
И при чем здесь look-and-feel?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Roman Odaisky, Вы писали:
I>>Я конкретно хочу услышать следующее — на WPF Нельзя сделать А и Б по причине В.
RO>На ‹вставить название сюда›, если можно нарисовать прямоугольник и управлять цветом пикселей, можно сделать всё.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Roman Odaisky, Вы писали:
I>>>Я конкретно хочу услышать следующее — на WPF Нельзя сделать А и Б по причине В.
RO>>На ‹вставить название сюда›, если можно нарисовать прямоугольник и управлять цветом пикселей, можно сделать всё.
I>Это такой демарш ?
В принципе он прав. Вопрос только в количестве времени, которое на это надо убить. С WPF мало, с какими-то другими технологиями, возможно, и на порядок(в 10 раз) больше.
Здравствуйте, Ikemefula, Вы писали:
C>>Конкретно небольшая часть фич для HTML+CSS показана здесь: I>Нужны фичи для HTMLLayout. Могу я в твоем html+css редакторе налепить например примитивов для векторной графики и ожидать, что в коде интеллисенс мне все это подскажет. Или же наоборот, в код налепить всякгого, а потом при редактировании html получать помощь в виде того же интеллисенса и разумеется все это при работе с примитивами
В IDEA — да
Здравствуйте, Ikemefula, Вы писали:
TBG>>Винда вообще подталкивает иметь сторонние программки, но никто не утвержает, что это неспроста. I>Представь себе, Микрософт не пичкает систему софтом, т.к. пользователи все разные.
А с чего библиотека должна пихать большую кучу функциональности, часто совсем ненужную?
I>Я вынужден пользоваться софтом писаным на джаве и мне лично это сильно не нравится по ряду причин, кои проявляются буквально везде, тотально. Ущербный УИ, кривой лайеут, недо-мега-контролы, тормоза и какой то отстой по RDP, при чем канал у меня где то 6 мбит
Не пиши больше сам софт на яве. Тем более, им не пользуйся. Потому как те причины, которые ты назвал — выдумка и фикция. И если у тебя действительно 6 мбит, то ты либо недоговариваешь, либо нагло врёшь, потому как даже на GPRS канале в 300 кбайт/с у меня ПИ swing'ов не тормозило.
Здравствуйте, x64, Вы писали:
x64>Я под WPF никогда не писал (под WinForms только опыт есть), а вот на днях попробовал форму хотя бы сделать простую и реально запутался. А у уж этот XAML мой моск вообще отказывается воспринимать. Т.е. вообще как-то странно получается, вроде занимаемся визуальным программированием, но при этом по-прежнему приходится ковырятся в каком-то (при чём незнакомом) языке. И возникает закономерный вопрос — а есть ли в этом XAML что-нибудь, что может заставить обычного шароварщика, скажем, писать свой UI именно под WPF? Особенно учитывая, что софт какой-нибудь системный больше и не требует никаких особых красивостей. Может быть там какие-то контролы есть новые на замену обычным системным? Что там такого есть, ради чего стоит таки потрахаться как следует с WPF-дизайнером и этим грёбанным XAML? Может хоть ссылочку дадите для начинающих в WPF? Особенно для тех, кто на него с WinForms переходит. Я пока даже не уверен вообще надо ли оно мне. Отговорите, а?
WPF — проще и удобнее. WinForms — привычнее. Сегодня я бы ничего не писал на WinForms, но это мое мнение. В WPF ничего сложного нет, если сходу непонятно, можно взять какую-то книженцию и прочитать вводные главы.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>Винда вообще подталкивает иметь сторонние программки, но никто не утвержает, что это неспроста. I>>Представь себе, Микрософт не пичкает систему софтом, т.к. пользователи все разные.
TBG>А с чего библиотека должна пихать большую кучу функциональности, часто совсем ненужную?
Если не нужно, то конечно не нужно.
I>>Я вынужден пользоваться софтом писаным на джаве и мне лично это сильно не нравится по ряду причин, кои проявляются буквально везде, тотально. Ущербный УИ, кривой лайеут, недо-мега-контролы, тормоза и какой то отстой по RDP, при чем канал у меня где то 6 мбит
TBG>Не пиши больше сам софт на яве.
Я никогда и не писал его, прикнь ? А вот пользоваться приходится.
>И если у тебя действительно 6 мбит, то ты либо недоговариваешь, либо нагло врёшь, потому как даже на GPRS канале в 300 кбайт/с у меня ПИ swing'ов не тормозило.
даже больше скажу, когда захожу RDP по локалке беспроводной, джавовские апплкации работают из рук вон плохо.
Здравствуйте, Codechanger, Вы писали:
RO>>>На ‹вставить название сюда›, если можно нарисовать прямоугольник и управлять цветом пикселей, можно сделать всё.
I>>Это такой демарш ?
C>В принципе он прав. Вопрос только в количестве времени, которое на это надо убить. С WPF мало, с какими-то другими технологиями, возможно, и на порядок(в 10 раз) больше.
А местами даже на два порядка больше. Про то и речь. Посему странно слышать про прямоугольник и управление цветом пикселей.
Здравствуйте, Ikemefula, Вы писали:
TBG>>Не пиши больше сам софт на яве. I>Я никогда и не писал его, прикнь ? А вот пользоваться приходится.
Сдаётся мне, что ты лукавишь.
>>И если у тебя действительно 6 мбит, то ты либо недоговариваешь, либо нагло врёшь, потому как даже на GPRS канале в 300 кбайт/с у меня ПИ swing'ов не тормозило. I>даже больше скажу, когда захожу RDP по локалке беспроводной, джавовские апплкации работают из рук вон плохо.
Обратись в службу поддержки Microsoft. У меня такого не наблюдается. Все приложения (кстати, не так двусмысленно, как аппликации) работают ровно так же, как и если бы не по RDP.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>Не пиши больше сам софт на яве. I>>Я никогда и не писал его, прикнь ? А вот пользоваться приходится.
TBG>Сдаётся мне, что ты лукавишь.
Да, открою правду — я учавствовал и учавствую во всех джава-проектах имеющих отногшение к UI.
I>>даже больше скажу, когда захожу RDP по локалке беспроводной, джавовские апплкации работают из рук вон плохо.
TBG>Обратись в службу поддержки Microsoft. У меня такого не наблюдается. Все приложения (кстати, не так двусмысленно, как аппликации) работают ровно так же, как и если бы не по RDP.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ikemefula, Вы писали:
C>>>Конкретно небольшая часть фич для HTML+CSS показана здесь: I>>Нужны фичи для HTMLLayout. Могу я в твоем html+css редакторе налепить например примитивов для векторной графики и ожидать, что в коде интеллисенс мне все это подскажет. Или же наоборот, в код налепить всякгого, а потом при редактировании html получать помощь в виде того же интеллисенса и разумеется все это при работе с примитивами C>В IDEA — да
Здравствуйте, CreatorCray, Вы писали:
C>>>Пиши на HTMLayout I>>Это из тех советов, которым следовать не стоит.
CC>Когда уже в Janus появится "пометить все ответы пользователя как прочитанные (и больше не скачивать их вовсе)"?
Здравствуйте, mrTwister, Вы писали:
C>>Удобное декларативное задание контролов (XAML отдыхает) T>Во-первых, это еще вопрос, что удобнее. Мне синтаксис Qt не показался очень удобным. И насколько он расширяем? Могу ли я писать свои Markup Extension'ы, конверторы и т.д.? Могу ли я его использовать для создания произвольных (своих собственных) объектов?
Да. Да.
C>>и анимация. T>И в чем именно Qt-шная анимация превосходит WPF-ную?
Более удобное задание. Ну и http://labs.trolltech.com/page/Projects/Graphics/Kinetic .
Здравствуйте, Codechanger, Вы писали:
C>Аргументы, приводившиеся тут до меня, приводить не буду, ибо Шеридан, скорее всего, MVVM никогда на практике не применял . Ну да лан. Далее. В пользу WPF играет такой немаловажный фактор, что это единственная на данный момент платформа, в которой разработку UI layout можно полностью отдать на откуп дизайнеру. И ведь разработает, не написав ни строчки кода.
Кхм. На HTMLayout это работает уже много лет. И этим реально пользуются.
Более удобное задание для кого? Для программиста, привыкшего к json? О вкусах не спорят. Сходив по ссылке, о преимуществах ничего не понял. В принципе можно простой пример — реализация окна с отражением контента окна.Естественно, с градиентной прозрачностью, всеми делами. Хотелось бы видеть примерчик на qt. Как это реализуется на wpf, можно посмотреть по ссылке: здесь. Раздел Example: Create a Reflection. Там даны две возможных реализации — чистый код и чистый XAML. Ждем результатов от адептов qt/HTMLayout. Не забывайте, пожалуйста, указывать затраченное время.
Здравствуйте, Codechanger, Вы писали:
C>здесь. Раздел Example: Create a Reflection. Там даны две возможных реализации — чистый код и чистый XAML. Ждем результатов от адептов qt/HTMLayout. Не забывайте, пожалуйста, указывать затраченное время. http://www.slideshare.net/qtbynokia/special-effects-with-qt-graphics-view — 16-я страница. Затраты кода — 10 строк.
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, Ikemefula, Вы писали:
I>>Нужны фичи для HTMLLayout. Могу я в твоем html+css редакторе налепить например примитивов для векторной графики и ожидать, что в коде интеллисенс мне все это подскажет. Или же наоборот, в код налепить всякгого, а потом при редактировании html получать помощь в виде того же интеллисенса и разумеется все это при работе с примитивами
Y>Интересный однако у вас стиль кодинга, налепить, наколбасить всякого, а потом смотреть, что же их этого вышло, и причем, для того, чтобы разобраться в том, что получилось, интеллисенс жизненно необходим
Вот представь, я сделал контрол в xaml, а потом в коде хочу его юзать. Правильная IDE тут же поможт мне это сдеать, несмотря на то что контрол в XAML.
И наоборот, контрол может быть сделан в коде, но я могу работать с ним в XAML.
Здравствуйте, Ikemefula, Вы писали:
TBG>>Обратись в службу поддержки Microsoft. У меня такого не наблюдается. Все приложения (кстати, не так двусмысленно, как аппликации) работают ровно так же, как и если бы не по RDP. I>А у меня не так же и Микрософт здеь ни при чем.
Ну так я тебе говорю, что это больная ситуация и у меня, например, не проявляется (хоть где-то windows работает). А так как RDP Microsoft поставляет со своими осями, то резонный совет обратиться в службу поддержки и подтюнить параметры. Подчёркиваю ещё раз — это больная ситуация, которая не проявляется у большинства народа.
Здравствуйте, Ikemefula, Вы писали:
I>Вот представь, я сделал контрол в xaml, а потом в коде хочу его юзать. Правильная IDE тут же поможт мне это сдеать, несмотря на то что контрол в XAML.
Вот представь, я сделал контрол в xaml, а потом хочу увидеть его в дизайнере правильного IDE и тут эшельбе мешельбе шайтанаме! Не показывает, говорит, мол ошибка какая-то
I>И наоборот, контрол может быть сделан в коде, но я могу работать с ним в XAML.
И наоборот, контрол может быть сделан в коде, и тут все прелести декларативных описаний и xaml улетучиваются в миг!
I>Но можешь и дальше дурака повалять.
Спасибо!
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, Ikemefula, Вы писали:
I>>Вот представь, я сделал контрол в xaml, а потом в коде хочу его юзать. Правильная IDE тут же поможт мне это сдеать, несмотря на то что контрол в XAML.
Y>Вот представь, я сделал контрол в xaml, а потом хочу увидеть его в дизайнере правильного IDE и тут эшельбе мешельбе шайтанаме! Не показывает, говорит, мол ошибка какая-то
Опять та же песня. Ну сколько можно твердить, что корректно XAML отображается только в скомпилированном приложении, когда подгружены все ресурсы?(ибо сценарии выбора тех же темплейтов могут быть достаточно сложными). Не в дизайнере счастье. И не может быть оно в нем. XAML сложноват все-таки для отображения в дизайнере. Тут что-то сродни веб-сайтам.
Здравствуйте, yumi, Вы писали:
I>>Вот представь, я сделал контрол в xaml, а потом в коде хочу его юзать. Правильная IDE тут же поможт мне это сдеать, несмотря на то что контрол в XAML.
Y>Вот представь, я сделал контрол в xaml, а потом хочу увидеть его в дизайнере правильного IDE и тут эшельбе мешельбе шайтанаме! Не показывает, говорит, мол ошибка какая-то
Значит так сделал. Любой дизайнер можно повалить при желании.
Здравствуйте, Codechanger, Вы писали:
C>Опять та же песня. Ну сколько можно твердить, что корректно XAML отображается только в скомпилированном приложении, когда подгружены все ресурсы?(ибо сценарии выбора тех же темплейтов могут быть достаточно сложными). Не в дизайнере счастье. И не может быть оно в нем. XAML сложноват все-таки для отображения в дизайнере. Тут что-то сродни веб-сайтам.
Я даже знаю, что эта за песня, эта песня о том, что, что-то все таки не так в консерватории.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, MxKazan, Вы писали:
MK>Вообще выражение присваивания через двоеточие, на мой взгляд, не самая читабельная конструкция. Обычное равно куда как нагляднее.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, squid, Вы писали:
s> MK>Вообще выражение присваивания через двоеточие, на мой взгляд, не самая читабельная конструкция. Обычное равно куда как нагляднее.
s> Не обижай Дельфистов, им и так тяжно...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, mrTwister, Вы писали: T>>Здравствуйте, x64, Вы писали: x64>>>Мда. Похоже, что мне ничего этого не нужно. T>>Ты знаешь, я тоже так думал, пока не начал этим пользоваться T>>ИМХО, у WPF главная проблема — это высокий порог вхождения. I>Не у WPF, а у декларатвного и функционального программирования вообще.
Любят же некоторые развести кашу. Ну при чем здесь функциональное программирование, и вообще программирование?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, yuriylsh, вы писали:
y>> Приятно удивлен информативностью твоего поста. Ожидал что ты просто поставишь смайлик...
S>Да я просто показываю реакцию многих местных программистов на опенсорц. S>Жаль только их топот и запах так лаконично не выразишь
Здравствуйте, dr.Chaos, Вы писали:
I>>даже больше скажу, когда захожу RDP по локалке беспроводной, джавовские апплкации работают из рук вон плохо.
DC>Странное дело, у меня тоже mergetool на C# писанный кошмарно долго рисуется по RDP, хотя KDE-шный Kompare мгновенно.
Приветствую, Mamut, вы писали:
M> GPL != Opensource M> Opensource = OSI approved licenses M> Очень большое количество народа в самом опенсорсе не любят GPL
Мамут как всегда достал свой насос и пытается его вставить мухе в ж...
M>> GPL != Opensource M>> Opensource = OSI approved licenses M>> Очень большое количество народа в самом опенсорсе не любят GPL
S>Мамут как всегда достал свой насос и пытается его вставить мухе в ж...
Здравствуйте, Sheridan, Вы писали:
S>ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111111111111111111111111111111111111одинодинодинодинодинодинодинодинодинодинодинодинодинодин
BTW: Htmlayout уже умеет правильно переносить такие строки чтобы верстка не ехала?
Здравствуйте, cgibin, Вы писали:
C>>В принципе можно простой пример — реализация окна с отражением контента окна.Естественно, с градиентной прозрачностью, всеми делами. Хотелось бы видеть примерчик на qt. Как это реализуется на wpf, можно посмотреть по ссылке: C>>здесь. Раздел Example: Create a Reflection. Там даны две возможных реализации — чистый код и чистый XAML. Ждем результатов от адептов qt/HTMLayout. Не забывайте, пожалуйста, указывать затраченное время.
C>HTMLayout, время секунд 10:
C>
Здравствуйте, Константин Б., Вы писали:
S>>ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111111111111111111111111111111111111одинодинодинодинодинодинодинодинодинодинодинодинодинодин
КБ>BTW: Htmlayout уже умеет правильно переносить такие строки чтобы верстка не ехала?
Лучше спросить в местном форуме по профилю, а то здесь никто даж ссылку на хорошую демку дать не может.
Здравствуйте, Ikemefula, Вы писали:
I>А теперь, что бы все были в равных условиях, покажи решение на JS VB и Джава
Причём здесь JS, VB и Java? Это CSS — т.е. декларативное описание интерфейса.
Здравствуйте, dr.Chaos, Вы писали:
I>>Что значит кошмарно долго ?
DC>Ну время полной отрисовки несколько секунд, при том что для QT-ешного Kompare это доли секунды.
Бывает и на дотнете пишут задней рукой. В случае с джавой это усугубляется недо-библиотеками.
Щас вот открыл мега-продукт, Идея 9.0.1, на первом же экране обнаружил артефакты, которые мы в своей дотнет прилаге не наблюдаем где то с первого релиза.
Здравствуйте, Cyberax, Вы писали:
I>>А теперь, что бы все были в равных условиях, покажи решение на JS VB и Джава C>Причём здесь JS, VB и Java? Это CSS — т.е. декларативное описание интерфейса.
При том, что не надо ничего никуда портировать, все работает сразу и на ура.
Более того, можно дать ссылку и на доку и на хорошую демку и на страничку с описанием всякой всячины, похожими проектами и тд и тд и тд,более того, в два-три клика все это опробовать.
Это называется технология и если хотя бы кое что в этом списке отсутствует, то до технологии еще как до небес.
Здравствуйте, Resnick, Вы писали:
C>>Сейчас нет QT, дома могу работающий пример сделать. R>А есть ли (точнее, будет ли в 4.х) в Qt аналог VisualBrush? Ведь Mirror (и прочее) по-разному можно делать.
Есть (и уже достаточно давно). Ты можешь рисовать компоненты элементов управления как хочешь: http://doc.trolltech.com/4.6/qstyle.html
Ну и любое дерево элементов ты можешь нарисовать на любой bitmap, а потом всё что угодно с этим bitmap'ом сделать.
Здравствуйте, Ikemefula, Вы писали:
C>>Ты бредишь или как? HTMLayout — это способ использования CSS+HTML для описания интерфейса. ЕСТЕСТВЕННО, не надо ничего никуда портировать. Пример с reflection'ом работает вообще без задания даже одной строчки кода. I>Т.е. нужная либа подключится сама собой ? зачем же ты под линукс портировал, если ничего не надо портировать ?
Так WPF на Линуксе сам собой не подключается, и даже вообще не работает. Вывод — WPF в топку.
Что-то ты бредишь уже.
Понятное дело, нужно подключить HTMLayout. Это делается абсолютно стандартно — подключается lib-файл в зависимости проекта, добавляется include directories. Для обёртки на Java ещё проще — просто стандартно прописывается зависимость от jar-файлов.
Как работает байндинг для .NET — не смотрел. Скорее всего, так же как и для Java.
C>>Скачиваешь HTMLayoutSDK и смотришь примеры. Там прекрасно всё демонстрируется. Отсутствие одной комплексной демки — это да, недостаток. I>Я уже посмотрел и не нашел ничего кроме одной крепкой либы. Ровно либа, до технологии как до небес.
Смотрел, но не увидел.
C>>Открытый API там тоже прекрасно задокументирован (он вообще там офигительно простой). Не знаю, ты может привык к монстроидальным API, в которых у каждой функции минимум по 20 параметров. В HTMLayout всё чрезвычайн просто. I>Я привык к технологиям.
Т.е. специально для тебя, нужно сделать функции с 20-ю параметрами?
LOL.
Технология в HTMLayout — это HTML+CSS. Ничуть не менее сложная или менее продвинутая, чем тот же WPF. Просто HTML+CSS — это СТАНДАРТНАЯ технология, её не надо специально для HTMLayout учить.
Здравствуйте, Cyberax, Вы писали:
C>Технология в HTMLayout — это HTML+CSS. Ничуть не менее сложная или менее продвинутая, чем тот же WPF. Просто HTML+CSS — это СТАНДАРТНАЯ технология, её не надо специально для HTMLayout учить.
Тока енто. Надо указывать, что стандартная для веба. Это раз. Следовательно, имеет ограничения, характерные для веба. Ну насчет байндингов так и не ответили.
Здравствуйте, Cyberax, Вы писали:
C>Есть (и уже достаточно давно). Ты можешь рисовать компоненты элементов управления как хочешь: http://doc.trolltech.com/4.6/qstyle.html
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, dr.Chaos, Вы писали:
I>>>Что значит кошмарно долго ?
DC>>Ну время полной отрисовки несколько секунд, при том что для QT-ешного Kompare это доли секунды.
I>Бывает и на дотнете пишут задней рукой.
Неужели?
I>В случае с джавой это усугубляется недо-библиотеками.
А разве библиотеки тоже не пишутся, а падают с небес?
Кстати, список java недобиблиотек в студию. Напротив каждой недобиблиотеки поставить соответствующую ей до-библиотеку .NET.
I>Щас вот открыл мега-продукт, Идея 9.0.1, на первом же экране обнаружил артефакты, которые мы в своей дотнет прилаге не наблюдаем где то с первого релиза.
Какие артефакты? Скриншоты в студию.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, hattab, Вы писали:
C>> Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода. H>Подожди, сейчас тебе напишут о текст боксе, с видео в бакграунде, вращающемся по часовой стрелке
Ааааааааааааааааааааааааааааааааааааааа!
Здравствуйте, Cyberax, Вы писали:
C>Ну я же сказал, что любую часть сцены можно отрендерить в битмап. И потом что угодно с ним делать. C> Вот тебе и VisualBrush будет.
а если VisualBrush привязан к MediaElement с видео? видео тоже в битмап отрендеришь
Здравствуйте, Cyberax, Вы писали:
C>Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
давай куб с отдельным видео из файла или камеры на каждой грани. как это сделано на WPF написал несколько выше, строчек 50 примерно. куб должен уметь крутиться в 3D, делать все по-честному.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Cyberax, Вы писали:
C>> Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
H>Подожди, сейчас тебе напишут о текст боксе, с видео в бакграунде, вращающемся по часовой стрелке
Уже написали
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, hattab, Вы писали:
C>>> Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода. H>>Подожди, сейчас тебе напишут о текст боксе, с видео в бакграунде, вращающемся по часовой стрелке C>Ааааааааааааааааааааааааааааааааааааааа!
Да нафиг надо? У WPF своя ниша, у HTMLayout своя. Делить им пока особо нечего.Тем более что доминирования HTMLayout на рынке десктопных приложений как-то не замечено.Ток вот на вопрос про биндинги Киберах так и не ответил... Я так подозреваю, их просто нет в силу того, что HTMLayout — тупо технология отображения. Ну далее продолжать спор смысла особого нет, ибо каждый, как обычно, останется при своей точке зрения.
Здравствуйте, squid, Вы писали:
C>> Вот тебе и VisualBrush будет. S>а если VisualBrush привязан к MediaElement с видео? видео тоже в битмап отрендеришь S>пример
Ну да. А кто мешает? У нас же нет анального DRM
Здравствуйте, LaPerouse, Вы писали:
LP> C>> Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
LP> H>Подожди, сейчас тебе напишут о текст боксе, с видео в бакграунде, вращающемся по часовой стрелке
LP> Уже написали
Приветствую, squid, вы писали:
s> давай куб с отдельным видео из файла или камеры на каждой грани. как это сделано на WPF написал несколько выше, строчек 50 примерно. куб должен уметь крутиться в 3D, делать все по-честному.
Здравствуйте, squid, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
S>давай куб с отдельным видео из файла или камеры на каждой грани. как это сделано на WPF написал несколько выше, строчек 50 примерно. куб должен уметь крутиться в 3D, делать все по-честному.
Пример примитивен. А если мне нужно на каждую грань вывести отдельное видео, начнется секс с UV-координатами и пример растолстеет раза в два. Кстати, а можно ли прямо там задать эффект для модели? Скажем, написать пиксельный шейдер, который обрезает видео с каждой стороны на 1/10 стороны куба? Если нельзя, то ценность всего этого равна нулю.
И еще. То, что реализовано в WPF для 3d останется игрушкой для школьника, пока в инструментариях для моделинга и текстуринга не появится импорт контента в WPF.
Социализм — это власть трудящихся и централизованная плановая экономика.
он малопригоден для игр по своей идеалогии. а вообще, штука очень мощная. полгода с ней работал. что касается кубика — загрузи любую другую модель и ее крути)))
так что, слив по полной как только о 3D речь заходит? а что в вашем стане с эффектами при помощи шейдеров?
C>Так я и знал, что кто-то про 3D заикнётся Тот 3D, который есть в WPF, ни на что кроме вращающегося кубика не пригоден.
Здравствуйте, LaPerouse, Вы писали:
LP>Пример примитивен. А если мне нужно на каждую грань вывести отдельное видео, начнется секс с UV-координатами и пример растолстеет раза в два.
нет. вообще проще сделать можель в 3D и потом экспортировать ее в XAML. лежит в ресурсах и есть не просит.
LP>Кстати, а можно ли прямо там задать эффект для модели? Скажем, написать пиксельный шейдер, который обрезает видео с каждой стороны на 1/10 стороны куба? Если нельзя, то ценность всего этого равна нулю.
Вообще, можно. Через пару недель как-раз буду подобную вещь делать. В качестве демки к мультимедийному SDK. Там правда будет несколько круче, несколько видео с источников вроде web-camer, тв тюнеров и IP камер.
LP>И еще. То, что реализовано в WPF для 3d останется игрушкой для школьника, пока в инструментариях для моделинга и текстуринга не появится импорт контента в WPF.
Экспорт в XAML есть, библиотеки для заргузки из других форматов (3ds например) тоже. Ты просто думай что ты собираешся делать на WPF, может тебе XNA сам DirectX нужен а не WPF.
Здравствуйте, squid, Вы писали:
C>>Ну да. А кто мешает? У нас же нет анального DRM S>показывай.
Так тот же reflection смотри.
S>З.Ы. S> а причем тут DRM вообще? воюешь с мельницами?
А как ты захватишь bitmap c protected content?
Здравствуйте, squid, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>>Пример примитивен. А если мне нужно на каждую грань вывести отдельное видео, начнется секс с UV-координатами и пример растолстеет раза в два. S>нет. вообще проще сделать можель в 3D и потом экспортировать ее в XAML. лежит в ресурсах и есть не просит.
Тогда зачем вообще для этого использовать XAML?
LP>>И еще. То, что реализовано в WPF для 3d останется игрушкой для школьника, пока в инструментариях для моделинга и текстуринга не появится импорт контента в WPF. S>Экспорт в XAML есть, библиотеки для заргузки из других форматов (3ds например) тоже. Ты просто думай что ты собираешся делать на WPF, может тебе XNA сам DirectX нужен а не WPF.
Я ничего не собираюсь и вообще далек от всего этого. Просто пытался представить, как это можно использовать. Похоже, что особо никак (см. выше).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP> LP>Тогда зачем вообще для этого использовать XAML?
для чего для этого? модель в одном файлике, эффекты прописаны в другом. все логично.
LP>Я ничего не собираюсь и вообще далек от всего этого. Просто пытался представить, как это можно использовать. Похоже, что особо никак (см. выше).
Здравствуйте, squid, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>> LP>>Тогда зачем вообще для этого использовать XAML?
S>для чего для этого? модель в одном файлике, эффекты прописаны в другом. все логично.
Я не совсем понял, почему модель должна быть в формате XAML. Какие это дает преимущества?
Социализм — это власть трудящихся и централизованная плановая экономика.
нативность для WPF, удобство помещения в ресурсы. можно и в другом, я 3ds использовал т.к. в этот формат можно отовсюду экспортировать.
LP>Я не совсем понял, почему модель должна быть в формате XAML. Какие это дает преимущества?
Здравствуйте, LaPerouse, Вы писали:
I>>Щас вот открыл мега-продукт, Идея 9.0.1, на первом же экране обнаружил артефакты, которые мы в своей дотнет прилаге не наблюдаем где то с первого релиза.
LP>Какие артефакты? Скриншоты в студию.
Здравствуйте, Cyberax, Вы писали:
I>>Демок нет, но технология есть Ну и цирк. Все надо делать вручную — и это технология ? C>Твой кретинизм достаёт.
Какой ты чувствительный.
C>Скачай HTMLayout и посчитай количество демок там. Их в районе 200 — более чем достаточно.
Для тупых, еще раз — все было скачано и посмотрено.
Демки слабые и демонстрируют убожество.
C>Просто нет одной большой демы, которая бы показывала сразу большинство функций.
Просто нет еще технологии, а есть всего лишь либа.
C>Я уже приводил примеры огромных контор, которые строят на HTMLayout свой бизнес. Что касается остального — работаю над этим.
Бизнес они на другом строят, а лайоут просто используют. Твой мега-мозг уже давно перегрелся, что бы это понять.
Просто HTML+CSS — это СТАНДАРТНАЯ технология, её не надо специально для HTMLayout учить. I>>При этом HTML+css Не может конкурировать с WPF. C>Ещё как может.
И в каой версии html+css появился биндинг?
I>>На это претендует HTMLLayout а ему в свою очередь до технологии как до небес. C>Чёй-то сторонники WPF как-то сдулись, когда их "невозможные" примеры с отражением решились в HTMLaout красиво и в 0 строк кода.
Я лично не дождался того что просил показать. Так что кто сдулся, тот еще вопрос.
Здравствуйте, LaPerouse, Вы писали:
T>>возможность рисовать вообще что угодно где угодно (например, ничто не мешает сделать кнопку, внутри которой лежит комбобокс, каждый элемент которого содержит прогресс бар и все это крутится по часовой стрелке), LP>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки
Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж.
Скажем, как мне в таблице сделать удобное редактирование ячеек? Никак, так как угрёбищная система с editor'ами никуда не годиться. Так же, нельзя нормально делать композитные контролы и т.п.
Здравствуйте, squid, Вы писали:
C>>А, то есть WPF нельзя использовать, на нём можно только Строить Бизнес. Понятненько. S>а люди то и не знают...
А я что, я сам офигел
Здравствуйте, Ikemefula, Вы писали:
I>>>Демки слабые и демонстрируют убожество. C>>Заглянул в MSDN. Демки слабые и демонстрируют убожество WPF. I>При этом они I>1. есть I>2. доступны в два три клика I>3. не требуют геморроя и лишних телодвиженй
Демки в HTMLayout, по большей части, открываются просто из HTMLayout Browser'а. В ноль кликов (т.е. просто открываешь им файл и смотришь дему).
Никакой компиляции и т.п.
I>>>Бизнес они на другом строят, а лайоут просто используют. Твой мега-мозг уже давно перегрелся, что бы это понять. C>>А, то есть WPF нельзя использовать, на нём можно только Строить Бизнес. Понятненько. I>WPF используется разными конторами но также вокруг него строится бизнес.
Что значит "вокруг него строится бизнес"?
I>>>И в каой версии html+css появился биндинг? C>>Где-то со второй, в конце 90-х. Смотри на http://www.w3schools.com/htmldom/default.asp — в HTMLayout используется оно. I>Это мягко говоря отстой а не биндинг.
Не WPF-овцам об этом говорить...
I>>>Я лично не дождался того что просил показать. Так что кто сдулся, тот еще вопрос. C>>ЧТО ТЫ ПРОСИЛ ПОКАЗАТЬ??? Мне так никто и не удосужился ответить. I>Вероятно твой кретинизм мешает поднять забрало да посмотреть.
Ты проговорил что-то про байндинг. Я так не понял что.
Здравствуйте, Cyberax, Вы писали:
LP>>За исключением кручения, все имеет непосредственную поддержку. На кнопку можно добавлять любой контрол. Для комбобокса можно установить рендерер ячейки C>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж.
C>Скажем, как мне в таблице сделать удобное редактирование ячеек? Никак, так как угрёбищная система с editor'ами никуда не годиться. Так же, нельзя нормально делать композитные контролы и т.п.
Здравствуйте, Cyberax, Вы писали:
C>Ну, пожалуйста, разъясните мне что за вопрос-то? Я уже от любопытства умираю.
Почитай тут http://msdn.microsoft.com/ru-ru/magazine/dd419663.aspx
Весь интерфейс живет на биндингах чуть менее чем полностью.
А если вместо C# взять немерле с парой простых как табуретка макросов то будет совсем айс.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
I>>>>И в каой версии html+css появился биндинг? C>>>Где-то со второй, в конце 90-х. Смотри на http://www.w3schools.com/htmldom/default.asp — в HTMLayout используется оно. I>>Это мягко говоря отстой а не биндинг. C>Не WPF-овцам об этом говорить...
Не мог бы ты подробнее написать об этом? Только без ссылок на "трели". Давай лучше своими словами: что так убоги биндинги WPF?
Здравствуйте, WolfHound, Вы писали:
C>>Ну, пожалуйста, разъясните мне что за вопрос-то? Я уже от любопытства умираю. WH>Почитай тут http://msdn.microsoft.com/ru-ru/magazine/dd419663.aspx WH>Весь интерфейс живет на биндингах чуть менее чем полностью.
Да я знаю, сделано оно очень классно.
Просто MVVM достаточно ортогонален к остальному. И у нас в Java-байндинге сейчас нечто подобное эволюционирует. В итоге сделаем ещё лучше, с использованием реактивного программирования.
Кстати, есть мысли как ввести автоматическое отслеживание зависимостей? Мне жутко понравился http://peak.telecommunity.com/DevCenter/Trellis (и более новый http://code.google.com/p/trellis-fork/ ) — там оно вообще всё автоматом работает. Т.е. меняешь данные в модели, и форма сама перерисовывает всё как надо. Или наоборот — меняешь форму, и данные в модели сами меняются. Причём с теоретической возможностью использовать многопоточность. Но завязано на динамику, к сожалению.
PS: я на досуге доказал, что обращение по индексам Z-кривой в массиве не выходят за диапазон. Получилось две страницы письменного текста... Нелинейные операции, однако...
Здравствуйте, MxKazan, Вы писали:
C>>>>Где-то со второй, в конце 90-х. Смотри на http://www.w3schools.com/htmldom/default.asp — в HTMLayout используется оно. I>>>Это мягко говоря отстой а не биндинг. C>>Не WPF-овцам об этом говорить... MK>Не мог бы ты подробнее написать об этом? Только без ссылок на "трели". Давай лучше своими словами: что так убоги биндинги WPF?
Очень примитивные.
Представь такую модельную ситуацию, есть элемент управления "дерево файловой системы", который отображает структуру каталогов и файлов. Всё абсолютно стандартно, никаких проблем.
Теперь в этот элемент добавляем label, в котором показывается размер на диске выбранного элемента и всех его детей. Тоже никаких проблем.
Теперь добавляем поддержку событий. Т.е. нам от операционной системы приходят оповещения "файл blah_blah изменился". Как мне сделать так, чтобы label с общим размером выбранного элемента корректно пересчитывался?
Или ещё усложним ситуацию — узлы дерева делаем редактируемыми (можно переименовывать файлы). Начинаем редактировать имя, а тут кто-то меняет имя родительского каталога. Как это обработать красиво?
Здравствуйте, MxKazan, Вы писали:
C>>Или ещё усложним ситуацию — узлы дерева делаем редактируемыми (можно переименовывать файлы). Начинаем редактировать имя, а тут кто-то меняет имя родительского каталога. Как это обработать красиво? MK>Погоди, погоди. Не надо вопросом на вопрос. Давай лучше ты скажешь, как эти задачи можно было бы решить, и где это уже сделано.
Суть в том, что у label'а тут есть неявная зависимость от элементов модели. И было бы интересно, если бы можно было такие неявные зависимости автоматически обрабатывать.
Я могу набросать пример на trellis'е (на Питоне).
MK>Не надо меня озадачивать. Тем более, что на мой взгляд, приведенные тобою проблемы совершенно не проблема и нормально решается в MVVM.
Нет, они решаются без проблем на чём угодно. На то он и модельный пример Тут вопрос в том, как они решаются.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Или ещё усложним ситуацию — узлы дерева делаем редактируемыми (можно переименовывать файлы). Начинаем редактировать имя, а тут кто-то меняет имя родительского каталога. Как это обработать красиво? MK>>Погоди, погоди. Не надо вопросом на вопрос. Давай лучше ты скажешь, как эти задачи можно было бы решить, и где это уже сделано. C>Суть в том, что у label'а тут есть неявная зависимость от элементов модели. И было бы интересно, если бы можно было такие неявные зависимости автоматически обрабатывать.
C>Я могу набросать пример на trellis'е (на Питоне).
Здравствуйте, MxKazan, Вы писали:
C>>Я могу набросать пример на trellis'е (на Питоне). MK>Давай. Можно даже просто подход описать.
Пример я напишу, а вся суть заключается в том, что мы для установки текста метки пишем вот такое:
И оно само пересчитается, если изменится то, от чего оно зависит. Понятное дело, что явный вызов setTitle может заменяться на декларативное указание в HTML/XAML — здесь это не важно.
Как пример, добавляем в подкаталог текущего каталога новый файл:
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Я могу набросать пример на trellis'е (на Питоне). MK>>Давай. Можно даже просто подход описать. C>Пример я напишу, а вся суть заключается в том, что мы для установки текста метки пишем вот такое: C>
C>И оно само пересчитается, если изменится то, от чего оно зависит. Понятное дело, что явный вызов setTitle может заменяться на декларативное указание в HTML/XAML — здесь это не важно.
C>Как пример, добавляем в подкаталог текущего каталога новый файл: C>
Здравствуйте, Cyberax, Вы писали:
C>И оно само пересчитается, если изменится то, от чего оно зависит. Понятное дело, что явный вызов setTitle может заменяться на декларативное указание в HTML/XAML — здесь это не важно.
Гм, так Binding-а здесь по сути и нет. Нечто вроде маппинга XAML на код и для WPF напридумывали, только оно не приживается как-то в силу того, что усложняет XAML, делает его слишком императивным и программируемым. А как _label узнает о том, что sum изменилась?
C>Как пример, добавляем в подкаталог текущего каталога новый файл: C>И метка автоматически пересчитывается. Без всяких манипуляций с моей стороны.
Чудес не бывает. Очевидно, что где-то есть "подлежащий" механизм оповещений. Кто его пишет и насколько он универсален?
C>Ну и там ещё STM, атомарность и всё такое...
Смысл этих страшных слов в контексте биндингов мне не знаком
Здравствуйте, WizardBox, Вы писали:
C>>Ну и там ещё STM, атомарность и всё такое... WB>Не понятно только одно, в чём сложность реализации этого в WPF?
Ну и как это сделать?
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, Cyberax, Вы писали:
C>>И оно само пересчитается, если изменится то, от чего оно зависит. Понятное дело, что явный вызов setTitle может заменяться на декларативное указание в HTML/XAML — здесь это не важно. MK>Гм, так Binding-а здесь по сути и нет. Нечто вроде маппинга XAML на код и для WPF напридумывали, только оно не приживается как-то в силу того, что усложняет XAML, делает его слишком императивным и программируемым.
Я не про то.
MK>А как _label узнает о том, что sum изменилась?
А вот это как раз и есть самое интересное
C>>Как пример, добавляем в подкаталог текущего каталога новый файл: C>>И метка автоматически пересчитывается. Без всяких манипуляций с моей стороны. MK>Чудес не бывает. Очевидно, что где-то есть "подлежащий" механизм оповещений. Кто его пишет и насколько он универсален?
Вот тут всё и чудо как раз. В Trelis'е отслеживается автоматически граф зависимостей, с помощью хитрых проксей, в которые оборачиваются объекты. Т.е. в прикладном коде не надо заботиться о том, что делается в UI.
На статических языках такое повторить затруднительно, но можно приблизиться. Хотя из-за этого придётся пересмотреть организацию байндинга.
C>>Ну и там ещё STM, атомарность и всё такое... MK>Смысл этих страшных слов в контексте биндингов мне не знаком
Ну как бы, та же проблема — в ходе изменения формы могут получаться невалидные промежуточные результаты.
Здравствуйте, Cyberax, Вы писали:
C>>>Как пример, добавляем в подкаталог текущего каталога новый файл: C>>>И метка автоматически пересчитывается. Без всяких манипуляций с моей стороны. MK>>Чудес не бывает. Очевидно, что где-то есть "подлежащий" механизм оповещений. Кто его пишет и насколько он универсален? C>Вот тут всё и чудо как раз. В Trelis'е отслеживается автоматически граф зависимостей, с помощью хитрых проксей, в которые оборачиваются объекты. Т.е. в прикладном коде не надо заботиться о том, что делается в UI.
Ну, а что конкретно то делается? Как эти классы могут определить, что walkDirectory зависит от createNewFile?
Здравствуйте, Cyberax, Вы писали:
C>Кстати, есть мысли как ввести автоматическое отслеживание зависимостей? Мне жутко понравился http://peak.telecommunity.com/DevCenter/Trellis (и более новый http://code.google.com/p/trellis-fork/ ) — там оно вообще всё автоматом работает. Т.е. меняешь данные в модели, и форма сама перерисовывает всё как надо. Или наоборот — меняешь форму, и данные в модели сами меняются. Причём с теоретической возможностью использовать многопоточность. Но завязано на динамику, к сожалению.
Не на динамику, а на метапрограммирование.
Те на немерле это можно повторить без проблем.
Но мне лень.
C>PS: я на досуге доказал, что обращение по индексам Z-кривой в массиве не выходят за диапазон. Получилось две страницы письменного текста... Нелинейные операции, однако...
Что-то многовато.
Доказывать короче мне совсем лень.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, MxKazan, Вы писали:
C>>Вот тут всё и чудо как раз. В Trelis'е отслеживается автоматически граф зависимостей, с помощью хитрых проксей, в которые оборачиваются объекты. Т.е. в прикладном коде не надо заботиться о том, что делается в UI. MK>Ну, а что конкретно то делается? Как эти классы могут определить, что walkDirectory зависит от createNewFile?
Создаваемые объекты оборачиваются в проксики, и при выполнении метода отслеживается к каким объектам (и коллекциям) были обращения. Этого достаточно, чтобы отследить зависимости.
Не в дизайнере счастье. И не может быть оно в нем. XAML сложноват все-таки для отображения в дизайнере.
Сейчас вы пишите:
Тут что-то сродни веб-сайтам.
А я об этом вам писал еще полгода назад:
В ASP.NET дизайнер улучшают с каждой версией (и пишут об этом в рекламных проспектах), но его использование до сих пор выглядит просто смешным. http://rsdn.ru/forum/design/3543799.1.aspx
Что случилось, вы таки поработали с WPF?
На будущее, если еще не хватает профессионального опыта (или просто мозгов), чтобы оценить новую технологию по архитектурным решениям, лежащим в ее основе, то не стоит повторять рекламных проспектов Майрософт-а. Тогда сначала поработайте с этой новинкой, прочувствуете на себе все прелести из рекламных проспектов, а потом уже пишите об этом в интернетах.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>Вот тут всё и чудо как раз. В Trelis'е отслеживается автоматически граф зависимостей, с помощью хитрых проксей, в которые оборачиваются объекты. Т.е. в прикладном коде не надо заботиться о том, что делается в UI. MK>>Ну, а что конкретно то делается? Как эти классы могут определить, что walkDirectory зависит от createNewFile? C>Создаваемые объекты оборачиваются в проксики, и при выполнении метода отслеживается к каким объектам (и коллекциям) были обращения. Этого достаточно, чтобы отследить зависимости.
Прикольно да. Хотя, в принципе, если будут обращения к объектам, которые взаимосвязаны логически, но в коде это никак не выражено, то GUI в будущем и не заметит зависимости.
C>Представь такую модельную ситуацию, есть элемент управления "дерево файловой системы", который отображает структуру каталогов и файлов. Всё абсолютно стандартно, никаких проблем.
C>Теперь в этот элемент добавляем label, в котором показывается размер на диске выбранного элемента и всех его детей. Тоже никаких проблем.
C>Теперь добавляем поддержку событий. Т.е. нам от операционной системы приходят оповещения "файл blah_blah изменился". Как мне сделать так, чтобы label с общим размером выбранного элемента корректно пересчитывался?
C>Или ещё усложним ситуацию — узлы дерева делаем редактируемыми (можно переименовывать файлы). Начинаем редактировать имя, а тут кто-то меняет имя родительского каталога. Как это обработать красиво?
MK>минусы индивидуального характера.
Очень хочется, чтобы вы были правы, но, к сожалению, это не так. Большинство описанных недостатков касаются основ WPF. Вряд ли удастся их исправить просто фиксами в будущих версиях. Framework 4 это подтверждает.
Здравствуйте, Alexander Polyakov, Вы писали:
MK>>минусы индивидуального характера. AP>Очень хочется, чтобы вы были правы, но, к сожалению, это не так. Большинство описанных недостатков касаются основ WPF. Вряд ли удастся их исправить просто фиксами в будущих версиях. Framework 4 это подтверждает.
Да никто не заставляет, собственно. Я только призвал к объективности. Жаль, что x64 оценил только отрицательные стороны, видимо это ему и было нужно.
Здравствуйте, MxKazan, Вы писали:
C>>Создаваемые объекты оборачиваются в проксики, и при выполнении метода отслеживается к каким объектам (и коллекциям) были обращения. Этого достаточно, чтобы отследить зависимости. MK>Прикольно да. Хотя, в принципе, если будут обращения к объектам, которые взаимосвязаны логически, но в коде это никак не выражено, то GUI в будущем и не заметит зависимости.
Ну так зависимости должны быть выражены в коде В принципе, не так уж много случаев, когда они не будут.
Здравствуйте, Cyberax, Вы писали:
C>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж.
В Swing-е оно сделано универсально
C>Скажем, как мне в таблице сделать удобное редактирование ячеек?
Известно как — выбирая нужную реализацию редактора содержимого ячейки через TableCellEditor.
C>Никак, так как угрёбищная система с editor'ами никуда не годиться.
Она очень гибка и универсальна. Ты имеешь дело только с текстовыми данными? А у меня к примеру в таблице отображаются и редактируются вектора. И концепция editor/renderer позволяет мне сделать это очень удобно.
C>Так же, нельзя нормально делать композитные контролы и т.п.
Что ты понимаешь под композитным контролом? Впервые слышу этот термин. Если это то, о чем я думаю, чем JPanel у примеру не подходит?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, LaPerouse, Вы писали:
I>>>Щас вот открыл мега-продукт, Идея 9.0.1, на первом же экране обнаружил артефакты, которые мы в своей дотнет прилаге не наблюдаем где то с первого релиза.
LP>>Какие артефакты? Скриншоты в студию.
I>Берешь и ресайзишь окна.
Мне нечего ресайзить. Я не пользуюсь Idea.
Социализм — это власть трудящихся и централизованная плановая экономика.
Недостаточно для чего? Для решения указанной задачи этого хватает за глаза. Из оверхеда — одна строчка кода в сеттере поля ViewModel — вызыать "OnPropertyChanged". И никакой магии не надо.
Здравствуйте, mrTwister, Вы писали:
T>>>http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx C>>Недостаточно даже близко. T>Недостаточно для чего? Для решения указанной задачи этого хватает за глаза. Из оверхеда — одна строчка кода в сеттере поля ViewModel — вызыать "OnPropertyChanged". И никакой магии не надо.
Нет. Тебе надо будет подписать метку на ВСЕ файлы в подкаталогах выбранного элемента. И при изменении выбранного элемента не забывать менять их.
Уже совсем не одна строчка. И это только для модельного примера. В реальных примерах всё сложнее.
Здравствуйте, LaPerouse, Вы писали:
C>>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж. LP>В Swing-е оно сделано универсально
Универсально через Ж.
C>>Скажем, как мне в таблице сделать удобное редактирование ячеек? LP>Известно как — выбирая нужную реализацию редактора содержимого ячейки через TableCellEditor.
Ага, и для активации редактора нужно на него щёлкнуть. При этом другой активный редактор выключается (т.е. редактор может быть только один). Попытки сделать редактор автоматически следующим за курсором приводят к жутким глюкам при клавиатурной навигации. И т.п.
В общем, у меня на SWING'е написано большое приложение. Так что не надо мне объяснять как оно всё круто работает. В HTMLayout, к примеру, этой проблемы нет в принципе.
И я уж не говорю, что те же таблицы в SWINGе сделаны криво. В JTable нет возможности сделать фиксированную колонку (заголовки рядов)! Или нельзя делать rowspan/colspan'ы.
C>>Так же, нельзя нормально делать композитные контролы и т.п. LP>Что ты понимаешь под композитным контролом? Впервые слышу этот термин. Если это то, о чем я думаю, чем JPanel у примеру не подходит?
Например, слайдер, у которого элемент, за который его таскают, работает как комбобокс. Про JPanel можешь мне не рассказывать
Здравствуйте, MxKazan, Вы писали:
T>>>Недостаточно для чего? Для решения указанной задачи этого хватает за глаза. Из оверхеда — одна строчка кода в сеттере поля ViewModel — вызыать "OnPropertyChanged". И никакой магии не надо. C>>Нет. Тебе надо будет подписать метку на ВСЕ файлы в подкаталогах выбранного элемента. И при изменении выбранного элемента не забывать менять их. MK>Какая-то фигня. В MVVM я бы просто сделал свойство Sum, get-аксессор которого подсчитывал нужную величину.
Ещё хуже. Детали пользовательского интерфейса проносим в модель.
MK>Добавив файл, при помощи события PropertyChanged оповестил бы интерфейс, что свойство Sum изменилось. Заранее отмечу, придирка что файл добавил бы кто-то иной без моего ведома не прокатывает, потому что, во-первых, это также можно решить одним оповещением, а во-вторых, врядли в этом случае меняется одна и та же коллекция. MK>И у меня возник такой вопрос: а как в Trellis решается ситуация, когда я не желаю, чтобы интерфейс реагировал на изменения в коллекции?
Можно игнорировать определённые изменения, но это считается очень плохим решением.
Здравствуйте, MxKazan, Вы писали:
MK>>>Какая-то фигня. В MVVM я бы просто сделал свойство Sum, get-аксессор которого подсчитывал нужную величину. C>>Ещё хуже. Детали пользовательского интерфейса проносим в модель. MK>Путаешь domain-model и view-model. Я говорил о второй.
А я с Trellis'ом могу от второй вообще отказаться. В любом случае, тебе вручную придётся где-то вести вычисления и слежение. Неудобно.
MK>>>И у меня возник такой вопрос: а как в Trellis решается ситуация, когда я не желаю, чтобы интерфейс реагировал на изменения в коллекции? C>>Можно игнорировать определённые изменения, но это считается очень плохим решением. MK>Ну, вот например, мне по бизнесу нужно произвести множество изменений в коллекции, зачем мне отображать промежуточные состояния пользователю?
Для этого там есть более нормальные средства (STM), которые позволяют делать "транзакции". Т.е. ты делаешь какое-то изменение, и перерасчёт зависимостей запускается только при его успешном завершении. Кстати говоря, сюда ещё и undo/redo совершенно логически приделываются.
Здравствуйте, Cyberax, Вы писали:
MK>>Путаешь domain-model и view-model. Я говорил о второй. C>А я с Trellis'ом могу от второй вообще отказаться.
Ну можно вообще от всего отказаться в обработчике нажатия кнопки лазить в базу данных. View-Model — это очень полезная штука без относительно твоего примера с перерисовкой view, которая позволяет сконцентрировать логику пользовательского интерфейса в одном месте в тестируемом виде.
Здравствуйте, mrTwister, Вы писали:
MK>>>Путаешь domain-model и view-model. Я говорил о второй. C>>А я с Trellis'ом могу от второй вообще отказаться. T>Ну можно вообще от всего отказаться в обработчике нажатия кнопки лазить в базу данных. View-Model — это очень полезная штука без относительно твоего примера с перерисовкой view, которая позволяет сконцентрировать логику пользовательского интерфейса в одном месте в тестируемом виде.
В том-то и дело, что я могу с помощью реактивного программирования тривиально связывать бизнес-логику и интерфейс.
Кстати, для .NET подобное тоже появляться начинает — LINQ for events и всё такое...
Здравствуйте, Cyberax, Вы писали:
C>В том-то и дело, что я могу с помощью реактивного программирования тривиально связывать бизнес-логику и интерфейс.
Интерфейс сам посебе может иметь сложную интерфейсную логику, которая никак не относится к бизнес-логике и тут нет прямой связи бизнес-логики с интерфейсом. Вот именно такую интерфейсную логику и помещают во ViewModel.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
C>>>В том-то и дело, что я могу с помощью реактивного программирования тривиально связывать бизнес-логику и интерфейс. T>>Интерфейс сам посебе может иметь сложную интерфейсную логику, которая никак не относится к бизнес-логике и тут нет прямой связи бизнес-логики с интерфейсом. Вот именно такую интерфейсную логику и помещают во ViewModel. C>Вот именно большую часть этой сложной логики и можно убрать с помощью реактивного программирования.
Куда убрать? Вот простейший пример: при установки чекбокса надо дизейблить кнопку. Куда ты предлагаешь убрать эту логику и как её тестировать?
Здравствуйте, mrTwister, Вы писали:
T>>>Интерфейс сам посебе может иметь сложную интерфейсную логику, которая никак не относится к бизнес-логике и тут нет прямой связи бизнес-логики с интерфейсом. Вот именно такую интерфейсную логику и помещают во ViewModel. C>>Вот именно большую часть этой сложной логики и можно убрать с помощью реактивного программирования. T>Куда убрать? Вот простейший пример: при установки чекбокса надо дизейблить кнопку. Куда ты предлагаешь убрать эту логику и как её тестировать?
Привязываешь свойство "disabled" кнопки к свойству "!selected" у чекбокса. Какие проблемы-то?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>Интерфейс сам посебе может иметь сложную интерфейсную логику, которая никак не относится к бизнес-логике и тут нет прямой связи бизнес-логики с интерфейсом. Вот именно такую интерфейсную логику и помещают во ViewModel. C>>>Вот именно большую часть этой сложной логики и можно убрать с помощью реактивного программирования. T>>Куда убрать? Вот простейший пример: при установки чекбокса надо дизейблить кнопку. Куда ты предлагаешь убрать эту логику и как её тестировать? C>Привязываешь свойство "disabled" кнопки к свойству "!selected" у чекбокса. Какие проблемы-то?
А кто сказал, что чекбокс — это единственная причина, по которой кнопка может быть задизейблена?
C>Тестировать как обычно — юнит-тестами.
Здравствуйте, Alexander Polyakov, Вы писали:
C>>Не в дизайнере счастье. И не может быть оно в нем. AP>Как же так, пол года назад я же говорил вам тоже самое (в тредах 1
AP>Не в дизайнере счастье. И не может быть оно в нем. XAML сложноват все-таки для отображения в дизайнере.
Вырываем цитаты из контекста.Путаем дизайнер и дизайнера(человека, который проектирует стили интерфейса без биндингов и прочего). AP>Сейчас вы пишите: AP>
AP>Тут что-то сродни веб-сайтам.
AP>А я об этом вам писал еще полгода назад: AP>
AP>В ASP.NET дизайнер улучшают с каждой версией (и пишут об этом в рекламных проспектах), но его использование до сих пор выглядит просто смешным.
AP>http://rsdn.ru/forum/design/3543799.1.aspx
Ну писали и писали. ЧСВ зашкаливает?
AP>Что случилось, вы таки поработали с WPF?
Ну кагбэ уже года три как, есличо. AP>На будущее, если еще не хватает профессионального опыта (или просто мозгов), чтобы оценить новую технологию по архитектурным решениям, лежащим в ее основе, то не стоит повторять рекламных проспектов Майрософт-а. Тогда сначала поработайте с этой новинкой, прочувствуете на себе все прелести из рекламных проспектов, а потом уже пишите об этом в интернетах.
З.Ы. Товарищ, ваш переход на личности(уже не в первый раз) начинает немного раздражать. Я-таки склоняюсь к мысли, что вас не мешало бы забанить на месяцок, чтобы научились общаться. Есть у вас точка зрения — отстаивайте ее аргументированно, без опускания оппонентов до своего уровня. Хотя о чем то бишь я, тут же священные войны.В общем, такие представители интеллектуального большинства, как Вы, уважаемый, попадаются в последнее время все чаще и чаще...
Здравствуйте, Codechanger, Вы писали:
C>>Привязываешь свойство "disabled" кнопки к свойству "!selected" у чекбокса. Какие проблемы-то? C>>Тестировать как обычно — юнит-тестами. C>Юнит тесты в подобной ситуации не очень помогут, к сожалению.Не видел я еще нормальных юнит тестов на UI(TestComplete в нос прошу не тыкать).
Кто не поможет?
Здравствуйте, mrTwister, Вы писали:
C>>Привязываешь свойство "disabled" кнопки к свойству "!selected" у чекбокса. Какие проблемы-то? T>А кто сказал, что чекбокс — это единственная причина, по которой кнопка может быть задизейблена?
Ну указываешь и другие причины. Какие проблемы-то?
C>>Тестировать как обычно — юнит-тестами. T>А пример можно?
См. в другом посте.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
C>>>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж. LP>>В Swing-е оно сделано универсально C>Универсально через Ж.
Есть другие предложения?
C>>>Скажем, как мне в таблице сделать удобное редактирование ячеек? LP>>Известно как — выбирая нужную реализацию редактора содержимого ячейки через TableCellEditor. C>Ага, и для активации редактора нужно на него щёлкнуть. При этом другой активный редактор выключается (т.е. редактор может быть только один). Попытки сделать редактор автоматически следующим за курсором приводят к жутким глюкам при клавиатурной навигации. И т.п.
Есть такое, но только концепция editor-ов тут не при чем.
C>И я уж не говорю, что те же таблицы в SWINGе сделаны криво. В JTable нет возможности сделать фиксированную колонку (заголовки рядов)! Или нельзя делать rowspan/colspan'ы.
Интересно. Я как раз искал таблицу с rowspan/colspan, нашел какую-то платную хрень, но она убога. Можно эту таблицу поместить в свинговый или awt-ный контейнер?
Swing имеет следующие преимущества:
1. Давно существует, хорошо известны недостатки, накоплен большой опыт использования.
2. Существует большое количество компонент. Например, есть ли в HTMLayout window docable manager? Для свингов существует более десяти. Большинство полная хрень, однако есть 4 шт. промышленного качества.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
C>>>>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж. LP>>>В Swing-е оно сделано универсально C>>Универсально через Ж. LP>Есть другие предложения?
В качестве первого приближения — XAML. Байндинги там на твёрдую четвёрку сделаны.
C>>Ага, и для активации редактора нужно на него щёлкнуть. При этом другой активный редактор выключается (т.е. редактор может быть только один). Попытки сделать редактор автоматически следующим за курсором приводят к жутким глюкам при клавиатурной навигации. И т.п. LP>Есть такое, но только концепция editor-ов тут не при чем.
Ещё как причём...
C>>И я уж не говорю, что те же таблицы в SWINGе сделаны криво. В JTable нет возможности сделать фиксированную колонку (заголовки рядов)! Или нельзя делать rowspan/colspan'ы. LP>Интересно. Я как раз искал таблицу с rowspan/colspan, нашел какую-то платную хрень, но она убога. Можно эту таблицу поместить в свинговый или awt-ный контейнер?
HTMLayout встраивается в SWING, у нас для этого специальный слой написан.
LP>Swing имеет следующие преимущества: LP>1. Давно существует, хорошо известны недостатки, накоплен большой опыт использования.
Угу, и его резюме: не надо использовать SWING.
LP>2. Существует большое количество компонент. Например, есть ли в HTMLayout window docable manager? Для свингов существует более десяти. Большинство полная хрень, однако есть 4 шт. промышленного качества.
Да ну. Как раз коммерческих контролов для SWING'а — самый мизер, особенно по сравнению с WPF.
Особенно прикольно это, учитывая что в Windows отказываются от docking manager'ов в пользу ribbon-like систем
Здравствуйте, vdimas, Вы писали:
I>>При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна.
V>Где именно она быстрее? На отрисовке сложных сцен? Ну так и уточняй. А пока что обычные GUI-приложения (где обычно десяток-другой контролов) WinForms запускаются в 2-3 быстрее и окошки заметно быстрее открываются.
При чем здесь сцены ? Читай свою же писанину
V>WPF в плане быстордействия обгоняет традиционный GDI пока только там, где много контролов и визуальных эффектов. Не уверен, что пора уже все обычные приложения украшать рюшечками эстетики ради, если за это мы поплатимся заметной разницей в скорости запуска приложения. Так что на сегодняшней реальности WPF — это вовсе не тул общего назначения.
Здравствуйте, vdimas, Вы писали:
V>И зря ты пытаешься спорить с WPF на их поле, преимущество HTMLayout совершенно в другом — факт использования его в многих очень известных программах тому подтверждение. Точно так же как отсутствие факта использования WPF хоть в какой-нить более-менее известной программе, кроме беты MS VS 2010.
AutoCAD использует WPF для интерфейса.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
C>>>>>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж. LP>>>>В Swing-е оно сделано универсально C>>>Универсально через Ж. LP>>Есть другие предложения? C>В качестве первого приближения — XAML. Байндинги там на твёрдую четвёрку сделаны.
А при чем здесь байндинги? Байндинг — это привязка данных к отображению, editors — это изменение данных. Байндинг для JTable делается через TableModel и никакого отношения к CellEditor-ам не имеет. Ты можешь сделать байнинги как в xaml или еще черт-знает где, но от editor-ов никуда не деться, если конечно тебе нужна нормальная таблица.
Вот пример. В моем приложении в таблице отображаются вектора токов, напряжений, мощностей и т. п, текстовые данные, комлексные числа и пр. Для редактирования векторов используется компонента VectorEditor. Для редактирования текстовых данных — JTextField. Для редактирования комплексных чисел — JPanel с двумя полями для ввода реальной и мнимой частей. Чем предлагаешь заменить это хозяйство?
C>>>Ага, и для активации редактора нужно на него щёлкнуть. При этом другой активный редактор выключается (т.е. редактор может быть только один). Попытки сделать редактор автоматически следующим за курсором приводят к жутким глюкам при клавиатурной навигации. И т.п. LP>>Есть такое, но только концепция editor-ов тут не при чем. C>Ещё как причём...
Да нет же. Editor — это лишь указание контроллеру таблицы, с помощью чего он должен менять данные определенного типа в таблице. А то, как он инициирует процесс редактирования — это реализация контроллера такая. Изменив ее, можно иметь хоть тысячу редакторов активных одновременно (если памяти хватит).
C>>>И я уж не говорю, что те же таблицы в SWINGе сделаны криво. В JTable нет возможности сделать фиксированную колонку (заголовки рядов)! Или нельзя делать rowspan/colspan'ы. LP>>Интересно. Я как раз искал таблицу с rowspan/colspan, нашел какую-то платную хрень, но она убога. Можно эту таблицу поместить в свинговый или awt-ный контейнер? C>HTMLayout встраивается в SWING, у нас для этого специальный слой написан.
Кстати, есть еще одна альтернатива свингу — RIA "apache pivot". На вид сыроват, но некоторые его хвалят.
LP>>Swing имеет следующие преимущества: LP>>1. Давно существует, хорошо известны недостатки, накоплен большой опыт использования. C>Угу, и его резюме: не надо использовать SWING.
Да я бы с удовольствием, да нет альтернативы. Ты сам это признал ниже
LP>>2. Существует большое количество компонент. Например, есть ли в HTMLayout window docable manager? Для свингов существует более десяти. Большинство полная хрень, однако есть 4 шт. промышленного качества. C>Да ну. Как раз коммерческих контролов для SWING'а — самый мизер, особенно по сравнению с WPF.
Коммерческие контролы мне нафиг не упали. Зато есть куча открытых контролов для любых нужд.
C>Особенно прикольно это, учитывая что в Windows отказываются от docking manager'ов в пользу ribbon-like систем
То есть нет и не надо А мне без этого никак.
Кстати, какое мне дело до того, кто и от чего отказывается в Windows? Я делаю кроссплатформенные приложения, но даже если бы писал под windows, в здравом уме не стал бы использовать ribbon.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ikemefula, Вы писали:
C>>>Вот конкретно в SWING'е оно сделано через Ж. Бааальшую Ж. C>>>Скажем, как мне в таблице сделать удобное редактирование ячеек? Никак, так как угрёбищная система с editor'ами никуда не годиться. Так же, нельзя нормально делать композитные контролы и т.п. I>>Ну что ты, swing это круто !!! C>Уже нет HTMLayout круче.
Может, для начала сделаешь docking manager для него?
<Шепотом, чтобы враги не услышали >: В WPF они есть.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
I>>>Ну что ты, swing это круто !!! C>>Уже нет HTMLayout круче. LP>Может, для начала сделаешь docking manager для него? LP><Шепотом, чтобы враги не услышали >: В WPF они есть.
Возможная реализация их есть в примерах. Мне, лично, они нафиг не сдались.
Здравствуйте, LaPerouse, Вы писали:
C>>В качестве первого приближения — XAML. Байндинги там на твёрдую четвёрку сделаны. LP>А при чем здесь байндинги? Байндинг — это привязка данных к отображению, editors — это изменение данных. Байндинг для JTable делается через TableModel и никакого отношения к CellEditor-ам не имеет. Ты можешь сделать байнинги как в xaml или еще черт-знает где, но от editor-ов никуда не деться, если конечно тебе нужна нормальная таблица.
Таки посмотри как XAML работает...
LP>Вот пример. В моем приложении в таблице отображаются вектора токов, напряжений, мощностей и т. п, текстовые данные, комлексные числа и пр. Для редактирования векторов используется компонента VectorEditor. Для редактирования текстовых данных — JTextField. Для редактирования комплексных чисел — JPanel с двумя полями для ввода реальной и мнимой частей. Чем предлагаешь заменить это хозяйство?
Всем тем же. Но как мне их поместить в таблицу? Проблема в том, что приходится делать ad-hoc модели и адаптеры-рисовальщики. Неудобно.
LP>Да нет же. Editor — это лишь указание контроллеру таблицы, с помощью чего он должен менять данные определенного типа в таблице. А то, как он инициирует процесс редактирования — это реализация контроллера такая. Изменив ее, можно иметь хоть тысячу редакторов активных одновременно (если памяти хватит).
Проблема в том, что таблицы вообще не должна знать ничего об editor'ах. Таблица должна заниматься layout'ом элементов управления, а как они там взаимодействуют уже с пользователем — не проблема таблицы.
LP>>>Интересно. Я как раз искал таблицу с rowspan/colspan, нашел какую-то платную хрень, но она убога. Можно эту таблицу поместить в свинговый или awt-ный контейнер? C>>HTMLayout встраивается в SWING, у нас для этого специальный слой написан. LP>Кстати, есть еще одна альтернатива свингу — RIA "apache pivot". На вид сыроват, но некоторые его хвалят.
Они пытаются придумать XAML, но без ресурсов MS у них фигня получится.
LP>>>1. Давно существует, хорошо известны недостатки, накоплен большой опыт использования. C>>Угу, и его резюме: не надо использовать SWING. LP>Да я бы с удовольствием, да нет альтернативы. Ты сам это признал ниже
Именно поэтому я начал развивать привязки HTMLayout для Java...
Здравствуйте, vdimas, Вы писали:
RO>>FreeType кажется какой-то чуждой, хотя эти продукты на порядок лучше того, что используют в MS. V>FreeType на малых разрешениях сливает TrueType, а в больших уже не принципиально.
FreeType использует TrueType. И Type 1, и OpenType. Ты имел в виду ClearType? Давай сравним.
Курсивная Джорджия, размеры все в пикселях, так что отрисовка ClearType должна быть тех же габаритов.
V>требовать "правильно отрисовывать" этот тест на <300 DPI — более чем глупо. На таких разрешениях нужна читабельность, а не точность позиционирования.
Без точности не будет читабельности. Как отрисовать подряд несколько букв шириной 2,4 пикселя?
Здравствуйте, vdimas, Вы писали:
V>Не в этом дело. Просто налицо несколько перекрывающих функциональность друг друга абстракций, и разработчики порой как те ослы у двух стогов сена, только здесь стогов больше. Особенно проблема заметна в отсутствии нескольких действительно нужных абстракций, например реализации отдельно скинов (аналога CSS), есть шаблоны представления, шаблоны данных и т.д., но нет шаблонов-шаблонов представлений, к которым привыкли в вебе, и это реально неудобно. Я бы еще добавил, что нет шаблонов-шаблонов данных, наподобие динамической раскраски ячеек Excel в зависимости от данных. Т.е., все это легко реализовать в конкретном шаблоне представления или шаблоне данных, вбить в дизайн гвоздями (или же косвено через ресурсы, не суть), но на лету менять такие "скины данных" — этого встроенного нет. Разумеется, можно писать самим, как внешнюю либу, и таких велосипедов уже хватает, но вот тут и встает такой момент, что было бы неплохо, чтобы этот тул гладко вошел во взаимодейтствие со всеми остальными абстракциями и своими велосипедами.
Что-то многих так и тянет сравнивать WPF с HTML и, не найдя привычных вещей, декларировать, что WPF крива... Но это я придираюсь, да и кривости есть местами.
Но интересно другое! Что это за шаблоны шаблонов такие? Какая нужна функциональность?
Здравствуйте, vdimas, Вы писали:
V>Owner draw был введен в win32 контролы для кастомизации их внешнего вида, а не создания других контролов на их основе. Ты не забыл, что сообщение идет паренту, а не самому себе? Это ключ к пониманию концепции, которая банальна в общем-то.
И что с того ? Отрисовка все равно убогая и даже для этой цели ownerdraw убог, при чем безнадежно.
V>А вообще, сравнивать GDI, которому около 30-ти лет, и WPF крайне глупо.
V>>Где именно она быстрее? На отрисовке сложных сцен? Ну так и уточняй. А пока что обычные GUI-приложения (где обычно десяток-другой контролов) WinForms запускаются в 2-3 быстрее и окошки заметно быстрее открываются.
I>При чем здесь сцены ? Читай свою же писанину
С первого раза не втыкается?
Попробуй не с первого. Хотя, и так понятно, где ты слажал — в термине "сцена". Издержки поверхностной эрудиции?
V>>WPF в плане быстордействия обгоняет традиционный GDI пока только там, где много контролов и визуальных эффектов. Не уверен, что пора уже все обычные приложения украшать рюшечками эстетики ради, если за это мы поплатимся заметной разницей в скорости запуска приложения. Так что на сегодняшней реальности WPF — это вовсе не тул общего назначения.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vdimas, Вы писали:
V>>И зря ты пытаешься спорить с WPF на их поле, преимущество HTMLayout совершенно в другом — факт использования его в многих очень известных программах тому подтверждение. Точно так же как отсутствие факта использования WPF хоть в какой-нить более-менее известной программе, кроме беты MS VS 2010. C>AutoCAD использует WPF для интерфейса.
Ну, автокад такого многогигового размера, что весь дотнет на его фоне теряется. А из повседневных программ? Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++? И кстати, судя по второй бете, это неплохо у них получается — MS Word запускает и работает гораздо шустрее предыдущих версий, по эффективности где-то на уровне Word 97. (ИМХО, Офис XP открыл линейку тормозных реализаций, похоже они это наконец поняли)
Здравствуйте, MxMsk, Вы писали:
MM>Но интересно другое! Что это за шаблоны шаблонов такие? Какая нужна функциональность?
Нужен аналог CSS, нужен доп. аттрибут аналогичный class="someCssClass" в HTML+CSS. Насколько я знаю, сейчас можно задать стиль только по типу элемента и его ID (x::Key), что есть статическое прибивание гвоздями. Нужен стиль, вот как меню на DHTML делаются? Активному элементу присваивается какой-нить class="menuSelected", и оно отображается не так, как остальные пункты.
Нужна система стилей, отвязанная от конкретных контролов, их типов и их ID, ибо слишком большая связанность получается. В принципе, все уже придумано в CSS. К тому же описывать стили в XML, в виде <Setter Property="" Value=""> — это чокнуться, очень плачевно.
И особено смешно, когда поднимается разговор о стилях, и кто-то пытается отсылать к функциональности связки св-в с динамическими или статическими ресурсами, которые в концептуальном плане недалеко ушли от ресурсов винапи.
Здравствуйте, Ikemefula, Вы писали:
I>И что с того ? Отрисовка все равно убогая и даже для этой цели ownerdraw убог, при чем безнадежно.
У тебя точно мысли не путаются?
Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен?
Скажу, что любой контрол можно закастамизировать безо всякого owner draw, напр. TabCtrl, owner draw вызывается только в том случае, если ты не переопределил процедуру рисования, т.е. если используется рисование по-умолчанию и стоит флаг owner draw, который говорит о том, что ты хочешь вмешаться лишь в процесс рисования табов, например, чтобы иконки там свои или как-нить табы цветом выделить. Хочешь полностью кастомно отрисовать — перехвати WM_PRINT/WM_PAINT/WM_ERASEBACKGROUND и рисуй сам с 0-ля как хочешь. Прицепи либу AGG, и нарисуешь все, что сможешь нарисовать в WPF.
V>>А вообще, сравнивать GDI, которому около 30-ти лет, и WPF крайне глупо.
I>Оконная система недалеко ушла от GDI.
Как она может от него уйти, если она на нем построена.
Че-то ты сегодня уже не впервой невпопад отвечаешь. Не выспался? Или откровенно не разбираешься в вопросе и нагло троллишь?
Здравствуйте, vdimas, Вы писали:
V>Ну, автокад такого многогигового размера, что весь дотнет на его фоне теряется. А из повседневных программ? Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++?
А почему не на HTMLayout или QT? Или что тут еще проскакивало — Swing? Вроде сто раз уже это обсуждалось...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, vdimas, Вы писали:
V>Есть и коммерческая.
А! Так вот о какой жадности Turtle.BAZON.Group говорил...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
V>>Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++?
Y>А почему не на HTMLayout или QT? Или что тут еще проскакивало — Swing?
Если брать MS Word, Excel, PP, то они сами себе HTMLayout. Тут надо спрашивать, почему не на AGG или похожей либе?
Так вот, DirectX мог бы ускорить всякие прокрутки и масштабирования. Далее, приложения офиса все-равно хранят как-то визуальные элементы в памяти — это могла быть одна и та же иерархия, корнем из дотнетного Visual.
Здравствуйте, yuriylsh, Вы писали:
Y>А! Так вот о какой жадности Turtle.BAZON.Group говорил...
Он вообще сам с собой по большей части разговаривает. Что касается QT, если брать деньги за подобные качественные либы есть жадность... то чем бы вы там с BAZON не занимались, коль вам ЗП платят, и вы ее подло берете, вы те еще жлобы.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
MM>>Но интересно другое! Что это за шаблоны шаблонов такие? Какая нужна функциональность?
V>Нужен аналог CSS, нужен доп. аттрибут аналогичный class="someCssClass" в HTML+CSS. Насколько я знаю, сейчас можно задать стиль только по типу элемента и его ID (x::Key), что есть статическое прибивание гвоздями. Нужен стиль, вот как меню на DHTML делаются? Активному элементу присваивается какой-нить class="menuSelected", и оно отображается не так, как остальные пункты.
Чем x:Key не аналог someCssClass?
V>Нужна система стилей, отвязанная от конкретных контролов, их типов и их ID, ибо слишком большая связанность получается. В принципе, все уже придумано в CSS. К тому же описывать стили в XML, в виде <Setter Property="" Value=""> — это чокнуться, очень плачевно.
А мне нравится
V>И особено смешно, когда поднимается разговор о стилях, и кто-то пытается отсылать к функциональности связки св-в с динамическими или статическими ресурсами, которые в концептуальном плане недалеко ушли от ресурсов винапи.
Ну да, по настоящему динамическими WPF-ные стили сделать не удастся. Если ссылку на стиль можно сделать динамической, то вот наследование (атрибут BasedOn) таким образом задать нельзя. Если бы MS открыл возможность пересоздания стилей по желанию, когда всё дерево заново конструируется, проблема бы пропала. Но пока этого нет и не знаю, появится ли. Поэтому, собственно, приходится жертвовать некоторыми достоинствами наследования, и тем не менее ничто не мешает менять связку "контрол-стиль" в рантайме.
Здравствуйте, vdimas, Вы писали:
V>У тебя точно мысли не путаются? V>Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен? V>Скажу, что любой контрол можно закастамизировать безо всякого owner draw, напр. TabCtrl, owner draw вызывается только в том случае, если ты не переопределил процедуру рисования, т.е. если используется рисование по-умолчанию и стоит флаг owner draw, который говорит о том, что ты хочешь вмешаться лишь в процесс рисования табов, например, чтобы иконки там свои или как-нить табы цветом выделить. Хочешь полностью кастомно отрисовать — перехвати WM_PRINT/WM_PAINT/WM_ERASEBACKGROUND и рисуй сам с 0-ля как хочешь. Прицепи либу AGG, и нарисуешь все, что сможешь нарисовать в WPF.
Да ладно. Понятно, что нарисовать можно всё что угодно, но таки кастомизация внешнего вида через контролы делается в WPF очень просто и наглядно.
Здравствуйте, vdimas, Вы писали: V>У тебя точно мысли не путаются? V>Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен? V>Скажу, что любой контрол можно закастамизировать безо всякого owner draw, напр. TabCtrl, owner draw вызывается только в том случае, если ты не переопределил процедуру рисования, т.е. если используется рисование по-умолчанию и стоит флаг owner draw, который говорит о том, что ты хочешь вмешаться лишь в процесс рисования табов, например, чтобы иконки там свои или как-нить табы цветом выделить. Хочешь полностью кастомно отрисовать — перехвати WM_PRINT/WM_PAINT/WM_ERASEBACKGROUND и рисуй сам с 0-ля как хочешь. Прицепи либу AGG, и нарисуешь все, что сможешь нарисовать в WPF.
Обычай же ассирийских крестин был таков: как только у царя рождался младенец мужского, женского или иного пола, сейчас же специально обученный писарь садился и, взяв в руки клинья, начинал писать на глиняных плитах имя новорожденного. Когда, истомленный трудом, писарь падал мертвым, его сменял другой и так дальше до тех пор, пока младенец не достигал зрелого возраста. К этому сроку все его имя считалось полностью и правильно написанным до конца.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Всё правильно, только опечатка, вместо WPF должно было быть Qt.
Почему все Qt приложения криво рендерят шрифты под Gnome?
Здравствуйте, vdimas, Вы писали:
V>У тебя точно мысли не путаются? V>Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен?
Точно знаю. Нормальная документация по овнердров появилаь уже с выходом дотнета, где то ближе ко второй версии. В нативном коде этим овнердров пользоваться крайне сложно, почти невозможно.
Овнердров этот более-менее хорошо сделан в DevExpress.
I>>Оконная система недалеко ушла от GDI.
V>Как она может от него уйти, если она на нем построена.
Вообще говоря она просто использует GDI и на нём не построена.
V>Че-то ты сегодня уже не впервой невпопад отвечаешь. Не выспался? Или откровенно не разбираешься в вопросе и нагло троллишь?
Шота ты сдуваться начал. Я вообще только вчера программировать научился.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, dr.Chaos, Вы писали:
DC>>Странное дело, у меня тоже mergetool на C# писанный кошмарно долго рисуется по RDP, хотя KDE-шный Kompare мгновенно.
V>Пару лет назад мы разработали свой протокол для шаринга приложений и пробовали при этом разные технологии для определения изменившихся областей экрана. Так вот, что интересно, хотя технология mirror driver, которую использует серверный компонент RDP и есть самая экономная в плане ресурсов сервера, но она же и самая неподходящая, если у гуиписателя руки не из того места растут. Т.е. надо перерисовать маленькую часть GUI, вместо этого современные программисты тупо делают refresh/invalidate всего и не парятся. Тоже самое при двойной буферизации. Поэтому сейчас, ввиду того, что интернет до сих пор не такой уж быстрый, а ресурсы современного компа ого-го, гораздо лучший результат дает технология тупого сканирования кадров с некоторой частотой, сравнения с предыдущими и кодировки только разницы.
Да там текст двух файлов рендериться со сглаживанием, т.к. этому .NET приложению пофиг на установки RDP. А вообще при прокрутке текста, в любом случае должно перерисовываться все поле вывода или, как минимум, его большая часть.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Без точности не будет читабельности. Как отрисовать подряд несколько букв шириной 2,4 пикселя?
V>Как их читать затем? V>Зачем переставлять местами причину и следствие? Уже вроде недавно об этом же поговорили, а ты все за свое...
V>Надо исходить из того, что есть, а есть около 100 DPI на современных мониторах, как бы тебе не хотелось иного. Для предпросмотра в системах верстки можно рендерить без хинтинга, чтобы убедиться, что все на месте, но для чтения — обязательно хинтинг со всеми искажениями в пользу позиционирования по пикселям, иначе зрению хана.
Меня наоборот коробит от таких шрифтов, потому я просто поставил себе dpi 120 и средний хинтинг и глаза не устают и читать приятно.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, fddima, Вы писали:
RO>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. F> Почему все Qt приложения криво рендерят шрифты под Gnome?
Плохо настроены, надо полагать. FreeType-то один на всех.
Здравствуйте, Roman Odaisky, я писали:
V>>FreeType на малых разрешениях сливает TrueType, а в больших уже не принципиально.
Картинку в студию так и не предоставили. Что ж, я сам сделал скриншот из MSIE. Сравним.
FreeType:
ClearType:
Размеры всё-таки разные, несмотря на то, что заданы они в пикселях. Это можно понять, настройки хинтинга разные. Для ClearType размер текста 8 и 8,5 пикселей — одно и то же. Ладно, разговор о точности позиционирования отложим на потом. Но кто мне скажет, что нижнее изображение читается лучше, или выглядит четче, или точнее передает форму букв шрифта, в того я первый брошу камень.
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>Всё правильно, только опечатка, вместо WPF должно было быть Qt. F>> Почему все Qt приложения криво рендерят шрифты под Gnome? RO>Плохо настроены, надо полагать. FreeType-то один на всех.
А почему Gtk это делает нормально?
Здравствуйте, fddima, Вы писали:
RO>>>>Плохо настроены, надо полагать. FreeType-то один на всех. F>>> А почему Gtk это делает нормально? RO>>Хорошо настроена, надо полагать. F> Т.е. реально использовать Qt нельзя. :-/
Я подозреваю, что это GTK сохранила свои настройки где-то отдельно, только для программ GTK, а не в ~/.fonts.conf, отчего все остальные программы, в т. ч. на Qt, использует дефолтные.
Приветствую, fddima, вы писали:
f> RO>>>Плохо настроены, надо полагать. FreeType-то один на всех. f> F>> А почему Gtk это делает нормально? f> RO>Хорошо настроена, надо полагать. f> Т.е. реально использовать Qt нельзя.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Так оно же на четверть длиннее. FreeType на такой длине будет выглядеть еще лучше.
Да.
RO>Насчет строчек особо мелких размеров, можно подумать, что масштабирование уже отменили, и никогда не нужно вглядеться в слово при маленьком масштабе.
Ну приведи примеры с нормальным размером и я возможно отвечу на твой вопрос иначе...
Здравствуйте, yuriylsh, Вы писали:
V>>Ну, автокад такого многогигового размера, что весь дотнет на его фоне теряется. А из повседневных программ? Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++? Y>А почему не на HTMLayout или QT?
"У них один фатальный недостаток" (c) не помню.
Y>Или что тут еще проскакивало — Swing? Вроде сто раз уже это обсуждалось...
SWING вообще на Java.
А пишут они его на С++ из-за того, что:
1) Куча legacy-кода.
2) У них достаточно ресурсов на это.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, yuriylsh, Вы писали:
V>>>Ну, автокад такого многогигового размера, что весь дотнет на его фоне теряется. А из повседневных программ? Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++? Y>>А почему не на HTMLayout или QT? C>"У них один фатальный недостаток" (c) не помню.
Ну если Microsoft вызывает такое желание поязвить, то возьми другую компанию с большим и долгоиграющим продуктом.
Y>>Или что тут еще проскакивало — Swing? Вроде сто раз уже это обсуждалось... C>SWING вообще на Java.
Да без разницы.
C>А пишут они его на С++ из-за того, что: C>1) Куча legacy-кода. C>2) У них достаточно ресурсов на это.
Ага. Теперь осталось сделать один маленький шажочек и понять что это-же относиться не только к языку, но и к платформе/библиотекам. Тогда ты ответишь на вопрос vdimas.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, yuriylsh, Вы писали:
V>>>Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++?
Y>>А почему не на HTMLayout или QT? Или что тут еще проскакивало — Swing?
V>Если брать MS Word, Excel, PP, то они сами себе HTMLayout. Тут надо спрашивать, почему не на AGG или похожей либе? V>Так вот, DirectX мог бы ускорить всякие прокрутки и масштабирования. Далее, приложения офиса все-равно хранят как-то визуальные элементы в памяти — это могла быть одна и та же иерархия, корнем из дотнетного Visual.
Y>>Вроде сто раз уже это обсуждалось...
V>И к чему пришли?
Смотри ответ Cyberax на один пост ниже. Ключевое слово legacy.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, yuriylsh, Вы писали:
Y>>>>А почему не на HTMLayout или QT? C>>>"У них один фатальный недостаток" (c) не помню. Y>>Ну если Microsoft вызывает такое желание поязвить, то возьми другую компанию с большим и долгоиграющим продуктом. C>Нокия и Symbian?
Что Нокия и Symbian?
C>>>А пишут они его на С++ из-за того, что: C>>>1) Куча legacy-кода. C>>>2) У них достаточно ресурсов на это. Y>>Ага. Теперь осталось сделать один маленький шажочек и понять что это-же относиться не только к языку, но и к платформе/библиотекам. Тогда ты ответишь на вопрос vdimas. C>Для WinForms не может быть пока особо много legacy.
Мой ответ все-таки касался переписывания Оффиса, там есть много legacy кода и там нету WinForms.
C> Вопрос с ресурсами — тоже не проходит, так как особой разницы между WinForms и WPF нет для конечного пользователя.
Не подскажешь, кстати, как считал разницу? И почему выбрана одна только метрика разницы для конечного пользователся при выборе инструментария разработчика, которая, кстати, отсутствует в твоих приведенных выше метриках?
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Y>>>>>А почему не на HTMLayout или QT? C>>>>"У них один фатальный недостаток" (c) не помню. Y>>>Ну если Microsoft вызывает такое желание поязвить, то возьми другую компанию с большим и долгоиграющим продуктом. C>>Нокия и Symbian? Y>Что Нокия и Symbian?
Ну как бы они на QT как раз мигрируют
C>> Вопрос с ресурсами — тоже не проходит, так как особой разницы между WinForms и WPF нет для конечного пользователя. Y>Не подскажешь, кстати, как считал разницу? И почему выбрана одна только метрика разницы для конечного пользователся при выборе инструментария разработчика, которая, кстати, отсутствует в твоих приведенных выше метриках?
Смотри, переход WinForms/WPF -> Native C++ даёт большие плюсы в startup time и потреблении памяти. Т.е. для конечного пользователя большой плюс. Так что компании с гигантским бюджетом могут пойти на поддержку интерфейса на С++, хотя на WPF всё будет быстрее.
А вот переход WinForms -> WPF не даёт существенной разницы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, yuriylsh, Вы писали:
Y>>>>>>А почему не на HTMLayout или QT? C>>>>>"У них один фатальный недостаток" (c) не помню. Y>>>>Ну если Microsoft вызывает такое желание поязвить, то возьми другую компанию с большим и долгоиграющим продуктом. C>>>Нокия и Symbian? Y>>Что Нокия и Symbian? C>Ну как бы они на QT как раз мигрируют
Что именно из этого мигрирует?:
UI Framework Layer
Application Services Layer
Java ME
OS Services Layer
generic OS services
communications services
multimedia and graphics services
connectivity services
Base Services Layer
Kernel Services & Hardware Interface Layer
Visual Studio тоже вроде как раз WPF мигрирует
C>>> Вопрос с ресурсами — тоже не проходит, так как особой разницы между WinForms и WPF нет для конечного пользователя. Y>>Не подскажешь, кстати, как считал разницу? И почему выбрана одна только метрика разницы для конечного пользователся при выборе инструментария разработчика, которая, кстати, отсутствует в твоих приведенных выше метриках? C>Смотри, переход WinForms/WPF -> Native C++ даёт большие плюсы в startup time и потреблении памяти.
Э-э-э, перехода с UI фрэймворка на язык программирования? Это как?
З.Ы. У меня вот VS 2010 стартует не медленней и жрет меньше памяти чем VS 2008...
З.З.Ы. Но ты все-таки не ответил насчет выбора метрик. Мол, какая удобна для дискуссии в данный момент ту и выбираем?
C>Т.е. для конечного пользователя большой плюс. Так что компании с гигантским бюджетом могут пойти на поддержку интерфейса на С++, хотя на WPF всё будет быстрее.
C>А вот переход WinForms -> WPF не даёт существенной разницы.
Инетерсные у тебя подходы к выбору языков, интерфейсов, и платфом Похоже, пора перемещать ветку в Архитектуру ну или на худой конец в Управление Проектами
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, MxMsk, Вы писали:
MM>Да ладно. Понятно, что нарисовать можно всё что угодно, но таки кастомизация внешнего вида через контролы делается в WPF очень просто и наглядно.
Про кастомизацию мы еще тут рядом про HTML CSS vs WPF STYLE не закончили, не торопись.
Тем более, что без ExpressionBlend особо внешний вид не накастомизируешь.
Здравствуйте, Ikemefula, Вы писали:
I>Точно знаю. Нормальная документация по овнердров появилаь уже с выходом дотнета, где то ближе ко второй версии. В нативном коде этим овнердров пользоваться крайне сложно, почти невозможно.
Нет слов...
Спасибо, а то в КУ затишье, хоть тут настроение поднимают.
I>Овнердров этот более-менее хорошо сделан в DevExpress.
Ммм... как бы это спросить помягче... Ты давно в отрасли?
Давай эту тему тупо закроем. Я понимаю, что ты, возможно, столкнулся с owner draw, но не потрудился разобраться, да и твоему поколению наверно уже и не зачем. Всё, забыли про owner draw, ему уже 30 лет скоро и пора его на помойку.
V>>Как она может от него уйти, если она на нем построена.
I>Вообще говоря она просто использует GDI и на нём не построена.
Вообще говоря, плохо у тебя получается упражняться в терминах, и не понятна цель подобного времяпрепровождения.
По нашему вопросу — оконная система виндов не может без GDI, невозможно подсунуть ей "нечто" вместо него, там все вшито намертво с односторонней зависимостью. А когда одна программная компонента использует таким неотъемлимым способом другую, говорят, что первая на второй построена (основана). Само по себе GDI — это абстракция графического устройства, поэтому грамотно будет говорить, что оконная система windows основана на абстракции GDI.
V>>Че-то ты сегодня уже не впервой невпопад отвечаешь. Не выспался? Или откровенно не разбираешься в вопросе и нагло троллишь?
I>Шота ты сдуваться начал. Я вообще только вчера программировать научился.
Раздражает просто, когда ты на собеседника время тратишь, обдумывая его фолианты, а он явно читает по-диагонали и не трудится напрягать кое-какой важный орган, что профанирует любое обсуждение до уровня бодания бичей в общественном месте.
Здравствуйте, vdimas, Вы писали:
V>Можно попросить тебя изобразить сначала простой пример: V>есть текстовые блоки на некоем визуальном представлении. Эти текстовые блоки бывают 3-х типов: обычные, цитирование и код. В каждом из блоков надо делать выделения. Эти выделения, в зависимости от текущего стиля, могут быть обозначены в виде рамки, другого цвета фона или повышенной жирности.
V>в CSS структуру стиля для этого можно описать примерно так: V>
V>И этот стиль будет дополнять стили остальных элементов, типа <H1>, <small>, <address> и т.д.
Не очень понял условия задачи. Как в твоем примере с css будет разруливаться какое выделение применять (рамка, цвет, жирность)? Может ты изобразишь сначала свой пример? Пока по аналогии на WPF можно описать примерно так :
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Y>>>Что Нокия и Symbian? C>>Ну как бы они на QT как раз мигрируют Y>Что именно из этого мигрирует?:
Собственно, всё. QT будет и Symbian'е, а старшие модели вообще на Линуксе (тоже с QT).
Y>Visual Studio тоже вроде как раз WPF мигрирует
Да, уже.
Y>>>Не подскажешь, кстати, как считал разницу? И почему выбрана одна только метрика разницы для конечного пользователся при выборе инструментария разработчика, которая, кстати, отсутствует в твоих приведенных выше метриках? C>>Смотри, переход WinForms/WPF -> Native C++ даёт большие плюсы в startup time и потреблении памяти. Y>Э-э-э, перехода с UI фрэймворка на язык программирования? Это как?
Имею в виду, на нативные фреймворки. Типа MFC, WinAPI.
Y>З.Ы. У меня вот VS 2010 стартует не медленней и жрет меньше памяти чем VS 2008... Y>З.З.Ы. Но ты все-таки не ответил насчет выбора метрик. Мол, какая удобна для дискуссии в данный момент ту и выбираем?
Метрики просто субъективны.
C>>А вот переход WinForms -> WPF не даёт существенной разницы. Y>Инетерсные у тебя подходы к выбору языков, интерфейсов, и платфом Похоже, пора перемещать ветку в Архитектуру ну или на худой конец в Управление Проектами
Я имею в виду разницу с точки зрения конечного пользователя. Для него примерно одинаково будет тормозить WinForms и WPF на запуске.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, yuriylsh, Вы писали:
Y>>>>Что Нокия и Symbian? C>>>Ну как бы они на QT как раз мигрируют Y>>Что именно из этого мигрирует?: C>Собственно, всё. QT будет и Symbian'е, а старшие модели вообще на Линуксе (тоже с QT).
Windows Phone 7 Series (меня всегда умиляло как Microsoft выбирает наименования — пока выговоришь, забудешь о чем говоришь ) на Silverlight мигрирует, что, как ты понимаешь, тоже managed код широко пересекающийся с WPF.
Y>>Visual Studio тоже вроде как раз WPF мигрирует C>Да, уже.
Y>>>>Не подскажешь, кстати, как считал разницу? И почему выбрана одна только метрика разницы для конечного пользователся при выборе инструментария разработчика, которая, кстати, отсутствует в твоих приведенных выше метриках? C>>>Смотри, переход WinForms/WPF -> Native C++ даёт большие плюсы в startup time и потреблении памяти. Y>>Э-э-э, перехода с UI фрэймворка на язык программирования? Это как? C>Имею в виду, на нативные фреймворки. Типа MFC, WinAPI.
И каков из этого вывод? Переход с WinForms/WPF -> MFC/WinAPI дает большие плюсы в startup time и потреблении памяти, отсюда следует ... ?
Y>>З.Ы. У меня вот VS 2010 стартует не медленней и жрет меньше памяти чем VS 2008... Y>>З.З.Ы. Но ты все-таки не ответил насчет выбора метрик. Мол, какая удобна для дискуссии в данный момент ту и выбираем? C>Метрики просто субъективны.
Это я уже заметил
C>>>А вот переход WinForms -> WPF не даёт существенной разницы. Y>>Инетерсные у тебя подходы к выбору языков, интерфейсов, и платфом Похоже, пора перемещать ветку в Архитектуру ну или на худой конец в Управление Проектами C>Я имею в виду разницу с точки зрения конечного пользователя. Для него примерно одинаково будет тормозить WinForms и WPF на запуске.
Ой-ли? Будет ли одно и тоже WinForms (или WPF) приложение одинаково тормозить если в сисетме уже запущено другое .Net приложение по сравнению со свеже-загружиной операционкой? А если это запуск второго инстаса того же приложения?
Но это все лирика. Я не пойму к чему ты клонишь. Имеешь в виду что твой джавовский порт HTMLayout идет в топку, ибо "Java -> Native C++ даёт большие плюсы в startup time и потреблении памяти" (c), "А вот переход Swing-> Java HTMLayout не даёт существенной разницы"(c)? "Я имею в виду разницу с точки зрения конечного пользователя. Для него примерно одинаково будет тормозить Swing и Java HTMLayout на запуске."(c)
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, vdimas, Вы писали:
V>В CSS у нас система координат из 4-х осей: элемент, его ID, класс и их взаимное расположение. Т.е., вот есть в HTML текстовые элементы: <H1>, <H2>, ... Cвязка Type+x:Key образуют всего лишь одну переменную, аналогично "элементу" в HTML. Не хватает хотя бы еще одной переменной, типа class (фиг с ним с ID, хотя с ним удобнее и выразительнее) и особенно не хватает декларативного описания взаимного расположения, эдакого шаблона для матча визуальных шаблонов, чтобы можно было описать декларативно: V>
V>element1.class1 element2 { /* тут описываем стиль element2 если он внутри element1 у которого class=class1 */}
V>element1, .class1, element2 element3.class3 { /* тут описываем стили сразу для 3-х меташаблонов */}
V>
Да, такого нет. Частично эта задача решается размещением стиля element2 в ресурсах element1.
V>>>Нужна система стилей, отвязанная от конкретных контролов, их типов и их ID, ибо слишком большая связанность получается. В принципе, все уже придумано в CSS. К тому же описывать стили в XML, в виде <Setter Property="" Value=""> — это чокнуться, очень плачевно. MM>>А мне нравится
V>Можно попросить тебя изобразить сначала простой пример: V>есть текстовые блоки на некоем визуальном представлении. Эти текстовые блоки бывают 3-х типов: обычные, цитирование и код. В каждом из блоков надо делать выделения. Эти выделения, в зависимости от текущего стиля, могут быть обозначены в виде рамки, другого цвета фона или повышенной жирности.
V>И этот стиль будет дополнять стили остальных элементов, типа <H1>, <small>, <address> и т.д.
Я, конечно, такой пример привести не могу, т.к. модель содержимого в WPF не дает такой возможности. Или я о ней не знаю, потому как с потоковыми документами практически не имел дела. Однако, это проблема не связана со стилями WPF. А так, можно создать 3 стиля. В чем проблема?
MM>>Ну да, по настоящему динамическими WPF-ные стили сделать не удастся. Если ссылку на стиль можно сделать динамической, то вот наследование (атрибут BasedOn) таким образом задать нельзя. Если бы MS открыл возможность пересоздания стилей по желанию, когда всё дерево заново конструируется, проблема бы пропала. Но пока этого нет и не знаю, появится ли. Поэтому, собственно, приходится жертвовать некоторыми достоинствами наследования, и тем не менее ничто не мешает менять связку "контрол-стиль" в рантайме.
V>Понимаешь, контролов должно быть мало, а одновременно используемых для одного контрола стилей на одной форме — много. В итоге, для получения некоего разнообразия надо наследоваться от контролов без добавления какой-либо функциональности, только для того, чтобы отделить типы контролов друг от друга "по смыслу" (т.е. получить аналог element из HTML), а уже x:Key использовать как доп. координату, аналог class. И все-равно, без меташаблонов, описывающих взаимное расположение, ничего серьезного в виде стилей описать не получится.. так, по мелочи разве что.
Да как-то дело привычки, по-моему. Никогда всерьез не занимался Вебом, поэтому не страдаю без чего-то подобного CSS. По мне так те же яйца только в профиль. Нет некоторых фич, но не так уж и часто они оказываются нужны.
V>Вот этот сценарий сегодня, когда поработал в VS, потом полез в ExpressionBlend, потом доработал код и отображение в VS, "поломались" стили, опять лезем в ExpressionBlend и так до бесконечности... Это такая, надо сказать, лажа... на самом высоком уровне. V>Они же себе ставили целью отделить работу художников от работы программиста, а на самом деле получилось в десятки раз более жестко одно на другое завязанно, чем даже в HTML.
Пока ты будешь рассматривать XAML сквозь призму HTML, тебе будут видится одни проблемы.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
MM>>Да ладно. Понятно, что нарисовать можно всё что угодно, но таки кастомизация внешнего вида через контролы делается в WPF очень просто и наглядно.
V>Про кастомизацию мы еще тут рядом про HTML CSS vs WPF STYLE не закончили, не торопись. V>Тем более, что без ExpressionBlend особо внешний вид не накастомизируешь.
Я подразумевал такую вещь, как шаблоны. Когда в ListBox в качестве элементов легко встраиваются редакторы этих элементов. Когда в заголовок вкладки можно спокойно воткнуть кнопку. Сделать такое на WinAPI — геморрой высшей степени.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Настройщик KDE как раз работает с .fonts.conf. Это GNOME/GTK используют что-то свое.
Если Qt работает в среде Gnome — это проблема именно Qt.
PS: Доберусь до конфигов — посмотрю точно.
M>>в 2010-м году уже как бы не хотелось настраивать отдельно Qt, отдельно GTK, отдельно еще что-то...
RO>Настройщик KDE как раз работает с .fonts.conf. Это GNOME/GTK используют что-то свое.
Эээ. А мне, как пользователю как-то на это наплевать, не? О чем я и говорил, говоря про 2010-й год. О каком вендекапце можно говорить, если две самых популярных десктоп-среды до сих пор не могут нормально совместно работать?
Здравствуйте, MxMsk, Вы писали:
MM>Я подразумевал такую вещь, как шаблоны. Когда в ListBox в качестве элементов легко встраиваются редакторы этих элементов. Когда в заголовок вкладки можно спокойно воткнуть кнопку. Сделать такое на WinAPI — геморрой высшей степени.
Здравствуйте, Ikemefula, Вы писали:
I>Правильно так — отрисковка в оконной системе виндов построена на GDI. Но сама оконная система виндов не сводится к отрисовке и потому в корне неверно утверждать что она построена на GDI.
Ну да, помимо отрисовки сама оконная система сводится еще к функциональности самой оконной системы.
Не надоело подставляться?
Здравствуйте, yuriylsh, Вы писали:
Y>Не очень понял условия задачи. Как в твоем примере с css будет разруливаться какое выделение применять (рамка, цвет, жирность)? Может ты изобразишь сначала свой пример? Пока по аналогии на WPF можно описать примерно так :
Y>
А как мне тогда задать отличие текста <H1> от <H2>?
Я же сказал, мало координат.
На самом деле все решаемо и я кое-какие попытки делал, например для x:Key можно ввести некий name convention, чтобы имя состояло из нескольких частей и прикрутить сверху некий хелпер-енжин, который этим управляет. Попытка реализовать вот ту описанную каскадность и аддитивность стилей и декларативную зависимость от взаимного расположения — вот тут я обломался, потому как дофига работы. Т.е. если встанет в реальном проекте необходимость — сделать можно, развлечения ради — слишком большая трудоемкость.
В принципе, тут не очем спорить, в интернете достаточно материала и сетований разработчиков на отсутствие функциональности, аналогичной каскадным стилям из HTML.
Даже такой момент — кто-нить видел, чтобы CSS-файлы продавали а деньги? А темы WPF/Silverlight продают аж бегом.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, dr.Chaos, Вы писали:
DC>>Меня наоборот коробит от таких шрифтов, потому я просто поставил себе dpi 120 и средний хинтинг и глаза не устают и читать приятно.
V>Ну, если монитор x>2k, y>1.5k, то так и надо. Если нет, то крупный шрифт неудобен.
Тебе неудобен (как и мне, зрение у меня хорошее). Но я знаю кучу народу которым очень даже удобен.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Codechanger, Вы писали:
C>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
Только корректнее будет убрать x:Key и оставить TargetType, без явного задания ссылки на стиль в Label.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Codechanger, Вы писали:
C>>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу. MM>Только корректнее будет убрать x:Key и оставить TargetType, без явного задания ссылки на стиль в Label.
Ну тут от задачи зависит. Это может быть как стиль по умолчанию, так и именованный. Я, собственно, x:Key поставил для наглядности. Реально он там, конечно, не нужен.
Все зависит от того что называть стилем. В WPF вообще нет строго разделения
на семантику и стиль. Скажем <StackPanel> это явно описание стиля контейнера (и/или поведения) — как он раскладывает своих children.
C>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
Да я как-то особо и не настаиваю именно на преимуществах того или иного подхода.
Например я же сказал: в WPF должно быть удобнее делать WYSIWYG в IDE.
Для вопрошающего товарища (a.k.a. topic starter) этот критерий является основополагающим.
Мне — нет. Т.е. все это сугубо субъективно.
Здравствуйте, Codechanger, Вы писали:
C>Данная конструкция тоже разделяется на две части: C>1. Объявление стиля C>2. Собственно разметка C>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
А как будет выглядеть стиль для превращения StackPanel во WrapPanel?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Codechanger, Вы писали:
C>>Данная конструкция тоже разделяется на две части: C>>1. Объявление стиля C>>2. Собственно разметка C>>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
TK>А как будет выглядеть стиль для превращения StackPanel во WrapPanel?
Если не прибивать StackPanel гвоздями к разметке страницы, то как-то так:
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxMsk, Вы писали:
V>>>А как мне тогда задать отличие текста <H1> от <H2>? MM>>А для чего тебе их отличать?
V>Затем, что x:Key используется для отличия блоков, навроде отличия <H1> от <H2>, т.е. уже занят.
Наследуй стили через BasedOn.
Здравствуйте, c-smile, Вы писали:
CS>Все зависит от того что называть стилем. В WPF вообще нет строго разделения CS>на семантику и стиль. Скажем <StackPanel> это явно описание стиля контейнера (и/или поведения) — как он раскладывает своих children.
Здесь нет никакого стиля. Это описание фабрики.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Codechanger, Вы писали:
C>>Данная конструкция тоже разделяется на две части: C>>1. Объявление стиля C>>2. Собственно разметка C>>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
TK>А как будет выглядеть стиль для превращения StackPanel во WrapPanel?
А это уже будет Template. В качестве примера см. ItemsControl.ItemsPanel. Я так понимаю, поставленная вами задача валидна только в случае отображения списка элементов. Другого практического применения я ей не вижу.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, c-smile, Вы писали:
CS>>Все зависит от того что называть стилем. В WPF вообще нет строго разделения CS>>на семантику и стиль. Скажем <StackPanel> это явно описание стиля контейнера (и/или поведения) — как он раскладывает своих children. MM>Здесь нет никакого стиля. Это описание фабрики.
И могу переключать вид как в markup так и в runtime.
Я могу это сделать так как HTML это чисто семантическая модель — не содержит в общем случае никаких "фабрик" и всего остального.
Но еще раз повторюсь: ответ на то хорошо это или плохо зависит от конкретных задач.
CS>И могу переключать вид как в markup так и в runtime. CS>Я могу это сделать так как HTML это чисто семантическая модель — не содержит в общем случае никаких "фабрик" и всего остального.
CS>Но еще раз повторюсь: ответ на то хорошо это или плохо зависит от конкретных задач.
Реализация в WPF ничем не отличается от твоей. Её уже, кстати anton_t показал: здесь
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, c-smile, Вы писали:
CS>>И могу переключать вид как в markup так и в runtime. CS>>Я могу это сделать так как HTML это чисто семантическая модель — не содержит в общем случае никаких "фабрик" и всего остального.
CS>>Но еще раз повторюсь: ответ на то хорошо это или плохо зависит от конкретных задач.
T>Реализация в WPF ничем не отличается от твоей. Её уже, кстати anton_t показал: здесь
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, mrTwister, Вы писали:
T>>Здравствуйте, c-smile, Вы писали:
CS>>>И могу переключать вид как в markup так и в runtime. CS>>>Я могу это сделать так как HTML это чисто семантическая модель — не содержит в общем случае никаких "фабрик" и всего остального.
CS>>>Но еще раз повторюсь: ответ на то хорошо это или плохо зависит от конкретных задач.
T>>Реализация в WPF ничем не отличается от твоей. Её уже, кстати anton_t показал: здесь
CS>А как в runtime разкоментировать скажем <StackPanel>?
CS>(Кто-то тут сказал что с XAML удобно в text editor работать. Месье знает толк в извращениях ...)
Раскомментарить не сложно: весь xaml — это сериализованное дерево объектов и с этим деревом из кода можно спокойно работать.
CS>А как в runtime разкоментировать скажем <StackPanel>?
Вариантов миллион. Например, можно декларативно триггером в зависимости от некоторого свойства модели применять тот или иной стиль. То есть делаем три стиля с разным лайаутом и прямо в xaml указываем какой стиль надо в каких случаях использовать.
Здравствуйте, vdimas, Вы писали:
I>>Нет, речь идет о "Windows provides three main categories of objects: user interface, graphics device interface (GDI), and kernel."
V>Ну и? Первый из этих компонентов построен на двух последующих, с чем ты споришь?
Здравствуйте, Ikemefula, Вы писали:
I>"жостко привязан" и "построен на" это разные
Дабы освежить тебе память, там было не только "построена", но и "основана", хотя в применении к ПО я считаю эти слова синонимами. Более полно озвучил сразу же: "оконная система основана на абстракции GDI", все-таки GDI — это не программная компонента, а интерфейс.
Или ты считаешь, что когда мы говорим, что одна программная компонента основана/построена на другой, то слово "построен/основан" в таком предложении является неким определенным термином? А нельзя ли озвучить сей "термин"? Ну чтобы я смог с тобой наконец согласиться или не согласиться...
Здравствуйте, vdimas, Вы писали:
V>Дабы освежить тебе память, там было не только "построена", но и "основана", хотя в применении к ПО я считаю эти слова синонимами. Более полно озвучил сразу же: "оконная система основана на абстракции GDI", все-таки GDI — это не программная компонента, а интерфейс.
Чушь. Оконная система в виндовсе это вагон кода из которого рендеринг занимает от силы 10%.
V>Или ты считаешь, что когда мы говорим, что одна программная компонента основана/построена на другой, то слово "построен/основан" в таком предложении является неким определенным термином? А нельзя ли озвучить сей "термин"? Ну чтобы я смог с тобой наконец согласиться или не согласиться...
Нужно смотрть на функционал, который предоставляет система. Про GDI+ можно сказать, что он построен на GDI потому что имеет место расширение функционала.
User32 это совершенно иной функционал по своей природе, нежели в GDI.
Здравствуйте, Roman Odaisky, Вы писали:
RO>FreeType использует TrueType. И Type 1, и OpenType. Ты имел в виду ClearType? Давай сравним.
RO>http://qwertty.com/tmp/ScreenTypographyTest-small.html RO>
RO>Курсивная Джорджия, размеры все в пикселях, так что отрисовка ClearType должна быть тех же габаритов.
Если бы я увидел такое в реальной программе, убил бы разработчика, и требовал суда присяжных. Оправдали бы.
Что касается знатоков нереальных программ, то надо ли из-за них ставить раком всех остальных?
Здравствуйте, yuriylsh, Вы писали:
RO>>Размеры всё-таки разные, несмотря на то, что заданы они в пикселях. Это можно понять, настройки хинтинга разные. Для ClearType размер текста 8 и 8,5 пикселей — одно и то же. Ладно, разговор о точности позиционирования отложим на потом. Но кто мне скажет, что нижнее изображение читается лучше, или выглядит четче, или точнее передает форму букв шрифта, в того я первый брошу камень. Y>Надо правильным IE пользоваться
Хм. У меня на 96DPI красивее выглядит IE, а вот на 120DPI на ноуте уже красивее FreeType.
Здравствуйте, SV., Вы писали:
SV.>Если бы я увидел такое в реальной программе
Берешь любимую читалку PDF, открываешь многостраничный PDF, сильно уменьшаешь масштаб, чтобы увидеть все страницы сразу. Можно подумать, что читабельность заголовков помешает.
SV.>Что касается знатоков нереальных программ, то надо ли из-за них ставить раком всех остальных?
И твое внимание я тоже обращу на то, что постановка задачи звучала именно так — «FreeType на малых разрешениях сливает TrueType» (очевидно, имелось в виду ClearType). На разрешениях побольше FreeType тоже превосходит ClearType.
Тем более, это же юникс-вей, хочется — поставь сильный хинтинг, хочется — задай особые настройки хинтинга для моноширинных шрифтов определенного размера. Но это уже издевательство над всеми достижениями типографики за последние 500 лет.
Здравствуйте, MxMsk, Вы писали:
V>>Затем, что x:Key используется для отличия блоков, навроде отличия <H1> от <H2>, т.е. уже занят. MM>Наследуй стили через BasedOn.
Так мне именно это базовые тоже менять надо, вернее все целиком, т.е. наследование не очень спасает. Позволит выстроить кое-какую иерархию, т.е. сэкономить на спичках, но по обсуждаемому вопрос не решает.
Здравствуйте, Cyberax, Вы писали:
C>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI.
А маки что — при отрисовке шрифтов не прибегают к этому субпиксельному жульничеству? Прибегают, как и все остальные. Куда ж им деваться, когда ваших крутых 150 dpi по-прежнему МАЛО для честной отрисовки. Вот будет больше в 4 раза, тогда перестанут. Вопрос в том, зачем вообще они этим занимаются. С макинтошниками все давно понятно, но ведь и те, кто массового потребителя обслуживает, сами соблязнулись и его... туда же.
Здравствуйте, SV., Вы писали:
C>>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI. SV.>А маки что — при отрисовке шрифтов не прибегают к этому субпиксельному жульничеству? Прибегают, как и все остальные. Куда ж им деваться, когда ваших крутых 150 dpi по-прежнему МАЛО для честной отрисовки.
Тем не менее, и на 96DPI можно пытаться передать реальную картинку. И Маки как раз это и делают.
SV.>Вот будет больше в 4 раза, тогда перестанут. Вопрос в том, зачем вообще они этим занимаются. С макинтошниками все давно понятно, но ведь и те, кто массового потребителя обслуживает, сами соблязнулись и его... туда же.
Ты просто думаешь, что то что тебе нравится — правильно.
Здравствуйте, SV., Вы писали:
SV.>Субпиксельный рендеринг как способ отобразить на мониторе шрифт похожим на тот же шрифт, но напечатанный в типографии — маргарин вместо масла, безвкусный, дешевый и вредный для здоровья заменитель. Хотя преподносится некоторыми как передний край прогресса. Преподносится, кстати, теми же людьми, которые рисуют лапки вместо старых добрых "".
Насчет засечек и DPI уже сказали. «Елочки» с „лапками“ служат той же цели. Текст с ними проще, быстрее и приятнее читать, чем с чужеродными для русского текста верхними кавычками. Скажи еще, что от привычных «книжных» кавычек воспринимаемость текста падает.
Кстати, правильная форма букв для русского языка важнее, чем для английского. Сравни:
abcdefghijklmnopqrstuvwxyz
абвгдежзиклмнопрстуфхцчшщъыьюэя
У русских букв намного меньше «хвостиков», что дает меньше зацепок глазу при чтении. Именно поэтому для кириллицы особенно важно передавать детали букв. Некритично, если шрифт потеряет свои характерные особенности, отличающие его от других шрифтов, но никуда не годится, если свои формы потеряют буквы.
SV.>Если, например, не культивировать сверхценность кавычек, свисающих скобок и более точной передачи гарнитур, то чем будет отличаться дизайнерская студия от студента-сайтостроителя?
На www.yandex.ru никакой особенной типографики нет. Просто информация там представлена четко и наглядно независимо от разрешения экрана и настроек шрифтов. Тем и отличается.
SV.>Это не полемика, а считаю я нужным вякнуть против. Прочитают немногие, но сила не за многими, а за умными.
Ты уверен, что множество умных и множество согласных с тобой совпадают?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, SV., Вы писали:
SV.>>Вопрос в том, зачем вообще они этим занимаются.
RO>Несглаженные символы — очень сильный хинтинг. RO>Очень сильный хинтинг — жесткая привязка к пикселям. RO>Жесткая привязка к пикселям — расползание при смене DPI. RO>Невозможность смены DPI — несглаженные символы.
RO>Субпиксельное сглаживание — возможность выйти из этого круга и перейти к мониторам, на которых оно постепенно станет ненужно.
На Маке и так жесткая привязка интерфейса к пикселям, еще хуже чем в винде. Так что наверное причина другая.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, Cyberax, Вы писали:
C>>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI.
SV.>А маки что — при отрисовке шрифтов не прибегают к этому субпиксельному жульничеству? Прибегают, как и все остальные. Куда ж им деваться, когда ваших крутых 150 dpi по-прежнему МАЛО для честной отрисовки. Вот будет больше в 4 раза, тогда перестанут. Вопрос в том, зачем вообще они этим занимаются. С макинтошниками все давно понятно, но ведь и те, кто массового потребителя обслуживает, сами соблязнулись и его... туда же.
А насчет маков... Я вот, например, простой программист, но после мака без слез на шрифты в других ОСях смотреть не могу. В других ОСях они просто уродливы. Поэтому маковцы всегда старались снабжать свои продукты диспеями бОльшими, чем было принято на тот момент в индустрии (1900x1200 на 17-дюймовых ноутах в то время, когда стандартом было 1440x900 и т.п.)
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Константин Б., Вы писали:
КБ>>На Маке и так жесткая привязка интерфейса к пикселям, еще хуже чем в винде.
RO>А в чём это выражается? (Для Маков не разрабатывал.)
1. В Apple Human Interface Guidelines все размеры элементов и шрифтов указаны в пикселях.
2. Как ведет себя апловский софт с изменением размеров шрифта http://rsdn.ru/forum/flame.comp/3580714.aspx
Здравствуйте, Cyberax, Вы писали:
C>Ты просто думаешь, что то что тебе нравится — правильно.
Это не я делаю СР неотключаемым, не я внедряю гарнитуры, которые сносно выглядят только при включенном СР, и не я убираю все шрифтовые настройки из интерфейса. Спрашивается, кто думает, что все, что он делает — правильно? (Это риторический вопрос).
Здравствуйте, Roman Odaisky, Вы писали:
RO>У русских букв намного меньше «хвостиков», что дает меньше зацепок глазу при чтении. Именно поэтому для кириллицы особенно важно передавать детали букв. Некритично, если шрифт потеряет свои характерные особенности, отличающие его от других шрифтов, но никуда не годится, если свои формы потеряют буквы.
Вам показать, какую форму имеют ваши буквы? Мне ж не трудно снять скриншот. На спектруме, может быть, была такая проблема. Да еще на тех компьютерах, которые использовали телевизор для вывода. Абсолютно надуманный аргумент.
RO>На www.yandex.ru никакой особенной типографики нет. Просто информация там представлена четко и наглядно независимо от разрешения экрана и настроек шрифтов. Тем и отличается.
И замечательно. И хорошо. Куча отличных сервисов, и как-то они не страдали от невозможности смещать текст на половинку пиксела влево-вправо. И такого ужаса, как на вашем скриншоте, у них я тоже не видел. Что и называется: реальное приложение.
КБ>1. В Apple Human Interface Guidelines все размеры элементов и шрифтов указаны в пикселях. КБ>2. Как ведет себя апловский софт с изменением размеров шрифта http://rsdn.ru/forum/flame.comp/3580714.aspx
Здравствуйте, SV., Вы писали:
C>>Ты просто думаешь, что то что тебе нравится — правильно. SV.>Это не я делаю СР неотключаемым, не я внедряю гарнитуры, которые сносно выглядят только при включенном СР, и не я убираю все шрифтовые настройки из интерфейса. Спрашивается, кто думает, что все, что он делает — правильно? (Это риторический вопрос).
Ты видел диалог настройки шрифтов в той же Убунте?
Теперь сравни это с отсутствием такого же диалога в Windows.
Здравствуйте, Константин Б., Вы писали:
C>>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI. КБ>150 DPI — это 15'' при 1920х1200 или 20'' при 2560х1600. Где вы такие мониторы берете? http://www.reviewgist.com/dell-xps-m1730
Хмм.. Наврали мне в документации, однако, реально там 133DPI Но текст выглядит всё равно шикарно.
Здравствуйте, Mamut, Вы писали:
КБ>>1. В Apple Human Interface Guidelines все размеры элементов и шрифтов указаны в пикселях. КБ>>2. Как ведет себя апловский софт с изменением размеров шрифта http://rsdn.ru/forum/flame.comp/3580714.aspx
КБ>>3. Утилита регулировки DPI запрятана в глубине Mac OS X developer tools. В интернетах пишут что результат применения — не ахти.
M>Вообще-то за это я лично немного зол на Apple По слухам Snow Leopard должен был стать resolution-independent. А вот хухъ там
Ну дык чудес не бывает. Я глядя на все их красивые окошки думал "Какая крутая штука этот Cocoa. Наверное там есть все эти лэйауты как в Qt.". А фиг там. Все так же как в винде, только официально разрешено прибивать гвоздями все к одному DPI и размеру шрифта.
Здравствуйте, Константин Б., Вы писали:
C>>Уже сейчас у меня монтиро с 150DPI. На нём маковские шрифты или FreeType смотрятся банально красивее, чем ClearType. Даже на нетбуке с 120DPI и то уже красивее FreeType. Так что удел ClearType — это нищеброды с экранами с 96DPI. КБ>150 DPI — это 15'' при 1920х1200 или 20'' при 2560х1600. Где вы такие мониторы берете?
вот например http://zoom.cnews.ru/goods_card/item/46448/hp-compaq-8510w
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, SV., Вы писали:
SV.>>Субпиксельный рендеринг как способ отобразить на мониторе шрифт похожим на тот же шрифт, но напечатанный в типографии — маргарин вместо масла, безвкусный, дешевый и вредный для здоровья заменитель. Хотя преподносится некоторыми как передний край прогресса. Преподносится, кстати, теми же людьми, которые рисуют лапки вместо старых добрых "".
RO>Насчет засечек и DPI уже сказали.
Засечки — это результат традиции. И идёт эта традиция из сложностей деланья букв на поверхностях и, далее, особенностей типографской печати — изначально все буквы были одинаковой ширины, так удобнее изготивливать гранки.
SV.>>«Елочки» с „лапками“ служат той же цели. Текст с ними проще, быстрее и приятнее читать, чем с чужеродными для русского текста верхними кавычками.
О, начинается... Чужеродные кавычки и исконно-потосконные лапки... Давайте еще пофлеймим о важности дефиса вместо тире(не путать с минусом!).
RO>Кстати, правильная форма букв для русского языка важнее, чем для английского. Сравни: RO>abcdefghijklmnopqrstuvwxyz RO>абвгдежзиклмнопрстуфхцчшщъыьюэя
Жульничаете. Где й, где ё? По читабельности — те-же "хвостики".
RO>У русских букв намного меньше «хвостиков»
10 в английском и 7 в русском(если считать все буквы, а не только те, что вы написали). Это "намного"?
Здравствуйте, Antikrot, Вы писали:
M>>
A>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее)
Такие в Мак ОС обычно. Там слабый вертикальный хинтинг, а ведь по вертикали разрешение обычно втрое меньше, чем по горизонтали. Кому как, мне вот тоже не нравится. Я бы предпочел что-то вроде этого:
Здравствуйте, Roman Odaisky, Вы писали:
A>>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее) RO>Такие в Мак ОС обычно. Там слабый вертикальный хинтинг, а ведь по вертикали разрешение обычно втрое меньше, чем по горизонтали. Кому как, мне вот тоже не нравится.
что-то я на маке не замечал раньше такого, чтоб прямо буквы выделялись. наверное он у меня был неправильно настроен
Здравствуйте, Antikrot, Вы писали:
YKU>>>О, начинается... Чужеродные кавычки и исконно-потосконные лапки... Давайте еще пофлеймим о важности дефиса вместо тире(не путать с минусом!). M>>Почему же, можно пофлеймить. M>>http://files.rsdn.ru/9088/Screen%20shot%202010-04-09%20at%2014.46.41%20.png M>>Это все же разные знаки с разной смысловой нагрузкой. И — да, с тире читать удобнее, чем с дефисом. M>>ЗЫ. В скришоте использованы все три тире. A>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее)
Здравствуйте, Roman Odaisky, Вы писали:
YKU>>Засечки — это результат традиции. И идёт эта традиция из сложностей деланья букв на поверхностях
RO>Что? А древние римляне, отливая буквы в бронзе, выбивая надписи на колоннах, использовали засечки, потому что так проще?
Насколько я знаю — именно так. Это связано с вотолкнистостью(дерево, да и в камне есть структура) и хрупкостью. На пальцах: вырубая букву I сначала ставились маленькие(и вырубленые с меньшей силой) горизонтальные чёрточки, после чего прорубался вертикальный канал. Если начать сразу вырубать глубокую борозду под вертикальную линию, то есть большая вероятность того, что материал треснет. Как-то так.
RO>Или средневековые писцы вырисовывали засечки, потому что писать без них сложнее?
А их и не вырисовывали. Это просто особенность техники письма.
"Засечки" весьма условны, есть только в начале и конце буквы(там, где перо начинает прикасаться к бумаге или отрывается от неё), образуются по вполне понятным причинам.
Короче, ИМХО засечки — это те самые традиции мёртвых поколений, которые кошмаром довлеют над умами живых.
Вообще, лично я бувы с засечками вижу только и исключительно в типографике. Все надписи на дорожных табличках, номерные знаки автомобилей(первое, что пришло в голову из раздела "это должно чётко читаться при беглом взгляде") без засечек. К чему бы это?
RO>Я всегда ставлю кавычки и тире, где нужно, из уважения к читателю. От других того не требую. Кто скажет, что так читать менее удобно, чем с ASCII-кавычками, в того я первый брошу камень.
Я не скажу, что это "менее удобно", это абсолютно безразлично. Как и "дефис-тире". Все, кого я знаю(ну, тут, конечно, круг знакомств важен) воспринимают их исключительно как приём двадцатого дана в кунг-фу грамарнаци.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, Mamut, Вы писали:
M>>>>
A>>>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее)
M>>Поому что скриншот из макоси в других ОСях, увы, будет выглядеть хуже.
КБ>В Макоси свой супер-пупер рендерер PNG ?
Здравствуйте, Roman Odaisky, Вы писали:
M>>>>Почему же, можно пофлеймить. DC>>http://pics.rsh.ru/img/rsdn_2baie.jpg RO>Давай пофлеймим. Когда уже перестанут использовать JPEG для того, для чего он не предназначен?!
Да просто данный хостинг не любит ничего другого.
RO>А смысла картинки я совершенно не улавливаю.
Здравствуйте, Mamut, Вы писали:
M>>>Поому что скриншот из макоси :) в других ОСях, увы, будет выглядеть хуже. КБ>>В Макоси свой супер-пупер рендерер PNG ? :)) M>разрешение выше :)
Здравствуйте, Mamut, Вы писали:
A>>>>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее) M>>>Поому что скриншот из макоси в других ОСях, увы, будет выглядеть хуже. КБ>>В Макоси свой супер-пупер рендерер PNG ? M>разрешение выше
сколько? у меня 1920х1200.
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, Константин Б., Вы писали: КБ>>Здравствуйте, Mamut, Вы писали: A>>>>кстати, только у меня текст на этом скриншоте выглядит на редкость отвратительно? (буква "т" и части других букв светлее) M>>>Поому что скриншот из макоси в других ОСях, увы, будет выглядеть хуже. КБ>>В Макоси свой супер-пупер рендерер PNG ? M>разрешение выше
Ну закачал картинку на телефон с 250 DPI. Лучше не стало.
Здравствуйте, Ikemefula, Вы писали:
MK>>А вот если ты подразумеваешь тормоза, то WPF безусловно достаточно требовательна. I>При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна.
Может в WPF есть специальная команда выключения тормозов? А то у меня наоборот получается WPF в разы медленнее чем GDI+.
Нарисуй 200x200 примитивов через drawingContext.DrawRectangle, GDI+ в разы быстрее, Direct3D/2D еще в разы быстрее.
Или вращающийся кубик в WPF бысрее чем в GDI+, только зачем один кубик нужен?
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Ikemefula, Вы писали:
MK>>>А вот если ты подразумеваешь тормоза, то WPF безусловно достаточно требовательна. I>>При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна. S_> Может в WPF есть специальная команда выключения тормозов? А то у меня наоборот получается WPF в разы медленнее чем GDI+. S_> Нарисуй 200x200 примитивов через drawingContext.DrawRectangle, GDI+ в разы быстрее, Direct3D/2D еще в разы быстрее. S_>Или вращающийся кубик в WPF бысрее чем в GDI+, только зачем один кубик нужен?
Здравствуйте, Silver_s, Вы писали:
I>>При всех своих тормозах она быстрее на порядок нежели GDI+ и винформс и более стабильна. S_> Может в WPF есть специальная команда выключения тормозов? А то у меня наоборот получается WPF в разы медленнее чем GDI+. S_> Нарисуй 200x200 примитивов через drawingContext.DrawRectangle, GDI+ в разы быстрее, Direct3D/2D еще в разы быстрее. S_>Или вращающийся кубик в WPF бысрее чем в GDI+, только зачем один кубик нужен?
Здравствуйте, Ikemefula, Вы писали:
S_>> Нарисуй 200x200 примитивов через drawingContext.DrawRectangle, GDI+ в разы быстрее, Direct3D/2D еще в разы быстрее. I>Не знаю, как ты сравнивал. покажи код.
Вот все что на WinForms требуется, эта беда за мышкой двигается. Попробуй напиши то же самое на WPF.
Только не предлагать двигать сам контрол со статическим рисунком, также не предлагать двигать рукой сам монитор
И вариант с WPF желательно не на 250 Ватных карточках запускать.
Если приведешь код на WPF который хотя бы не более чем в 2 раза медленнее чем WinForms GDI+, скажу огромное спасибо.
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
DoubleBuffered = true;
}
protected override void OnPaint(PaintEventArgs e)
{
var g=e.Graphics;
g.Clear(Color.White);
for (int i = 0; i < 900; i += 900 / 200)
for (int j = 0; j < 900; j += 900 /200)
{
g.DrawRectangle(Pens.Black, x + i, y+j, 5, 5);
}
}
int x, y;
private void UserControl1_MouseMove(object sender, MouseEventArgs e)
{
x = e.X;
y = e.Y;
Invalidate();
}
}
На WPF как-то так
Pen myPen = new Pen(Brushes.Blue, 1);
myPen.Freeze();
Rect myRect = new Rect(0, 0, 5, 5);
for (int i = 0; i < 900; i += 900 / 200)
for (int j = 0; j < 900; j += 900 /200)
{
Rect r = myRect;
r.Offset(dp.X + i, dp.Y + j);
drawingContext.DrawRectangle(null, myPen, r);
}
Здравствуйте, MxMsk, Вы писали: MM>О, ну да, 200x200 прямоугольничков в разы нужнее вращающегося кубика
Одного кубика мало. Хотя бы 1000 кубиков надо
Попробуй нарисуй полностью кастомный контрол на WPF, какой нибудь сложный грид совмещенный с группированием через раскрывающиеся узлы как в TreeView, с большим числом ячеек, со сложной структурой ячеек,редактированием. Тогда все слабости WPF раскроются во всей красе, и архитектурные и по производительности.
Для формирования документов в стиле HTML конечно WPF хорош но этого мало.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, MxMsk, Вы писали: MM>>О, ну да, 200x200 прямоугольничков в разы нужнее вращающегося кубика S_> Одного кубика мало. Хотя бы 1000 кубиков надо S_>Попробуй нарисуй полностью кастомный контрол на WPF, какой нибудь сложный грид совмещенный с группированием через раскрывающиеся узлы как в TreeView, с большим числом ячеек, со сложной структурой ячеек,редактированием. Тогда все слабости WPF раскроются во всей красе, и архитектурные и по производительности. S_> Для формирования документов в стиле HTML конечно WPF хорош но этого мало.
Кагбэ лечится виртуализацией, пейджингом и т.д.Кривизна интерфейса(как и его тормоза) обычно в большей степени зависят от автора, а не от технологии.
[offtop]Эта... как только появляется настолько сложный интерфейс(деревья в гриде, большое число ячеек и т.д.), я сразу задаюсь вопросом — а на кой ляд все это надо? Работать ведь не оч удобно.[/offtop].
упс, должно быть i += 900 / 200 а не i += 1000 / 200
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Хорошо хоть такая возможность всегда есть. Но Direct2D такое не обгонит. Разве что в D2D тоже битмапы заготавливать для WPF.
Всё тоже самое доступно и в XAML, но с другим синтаксисов. Несомненно, в чём-то синтаксис (и структура организации) HTML/CSS лучше/удобнее XAML, в чём-то наверняка нет, а суть в том, что функционально они … инструменты одного порядка, никто из нах не на порядок лучше другого.
Ожидал что ты просто поставишь смайлик...
