IT wrote: > Если ты конкретно про веб-дизайнер, то, действительно, лучше бы его не > было. Все кого я знаю кто серьёзно занимается вебом отключают дизайнер > сразу. Но без дизайнера гуёвых форм жить нельзя. Пристреливать контрол > по пикселям в коде с постоянной перекомпиляций для проверки попадания — > дело не для слабонервных.
Эээ... А про "layout managers" вы слышали?
У меня в Java через некоторое время использования layout'ов в Swing (и
SWT) пропало желание использовать GUI-дизайнеры вообще.
Хотя что-то типа wxGlade'а — тоже вполне нормально (так как позволяет
визуально смотреть иерархию лэйаутов).
Здравствуйте, McSeem2, Вы писали:
IT>>Если ты конкретно про веб-дизайнер, то, действительно, лучше бы его не было. Все кого я знаю кто серьёзно занимается вебом отключают дизайнер сразу. Но без дизайнера гуёвых форм жить нельзя. Пристреливать контрол по пикселям в коде с постоянной перекомпиляций для проверки попадания — дело не для слабонервных.
MS>И это верно. А чем же они тогда пользуются, если сразу отключают? Есть какая-то альтернатива?
Переключаются в html код. Проще и эффективней. Работают подсветка синтаксиса и автокомплит.
MS>Да и просто дизайнер форм для десктоп-приложений — то еще уродство. Вообще, "пристреливание по пикселам" — это по большому счету все, что требуется от ГУИ-дизайнера.
Не совсем так. Кроме пикселей есть ещё куча свойств, который нужно контролировать. Тот же TabOrder, например, шрифты, цвет, баиндинг. В отличии от просто кода, я гораздо быстрее нахожу то место, которое мне нужно поменять. Клик на контрол и я уже где надо. Хотя могу сказать, я не фанатею от редакторов форм и если нужно шаловливые ручки запустить в сгенерированный код, то я делаю это без проблем, елси, конечно, понимаю, что делаю.
MS>Все эти рукоблудства с генерированием кода — не более чем маркетинговый тотал-булшит.
Сохранение в ресурсах выглядело бы короче. Но сгенерированный код можно править самому, что есть гуд. Я к этому прибегаю довольно часто, особенно для всяких поисков замен и удаления лишнего. К тому же он довольно оптимален. Жирный сгенерированный код — это кривые ручки писателя контрола, но никак не писателей редактора форм.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
C>Эээ... А про "layout managers" вы слышали?
Слышали и видели и даже в руках держали. Частично это помогает, но от покрытия нужных мне 100% случаев layout manager'у как без языка до Киева. К тому же размеры контролов, цвет, шрифт и прочую мелочовку он не менеджит. Т.е. удобное средство, решающее свои конкретные задачи, на универсальный подход не претендующее.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: > C>Эээ... А про "layout managers" вы слышали? > Слышали и видели и даже в руках держали. Частично это помогает, но от > покрытия нужных мне 100% случаев layout manager'у как без языка до > Киева.
Не знаю, вот в Eclipse их для всего хватает. AbsoluteLayout там вообще
не используется нигде в стандартной поставке.
> К тому же размеры контролов, цвет, шрифт и прочую мелочовку он не > менеджит.
Как раз размеры менеджаться спокойно (в соответствующих layout'ах).
Шрифтов обычно используются один-два на форму, так что с ними проблем
обыно нет. Для подбора цветов есть плугины к IDE.
> Т.е. удобное средство, решающее свои конкретные задачи, на > универсальный подход не претендующее.
Эти задачи покрывают фактически 99% всего.
Здравствуйте, Cyberax, Вы писали:
C>Эти задачи покрывают фактически 99% всего.
Т.е. к layout manager'ом дело не заканчивается, ты ещё используешь ещё кучу всяких приблуд
Правильно? А то я уж подумал, что в джаве всего лишь одна кнопка, которая называется "layout manager".
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: > C>Эти задачи покрывают фактически 99% всего. > Т.е. к layout manager'ом дело не заканчивается, ты ещё используешь ещё > кучу всяких приблуд > Правильно?
Ну еще и контролы нужны, естественно. Но 99% задач с построением
формочек (то есть то что делает form-designer) решаются layout'ами,
причем обычно красивее и удобнее.
Например, с помощью layout'ов обычно очень легко сделать масштабируемые
формы. Или формы, которые будут работать с настройками шрифта "Очень
крупный". А вот в дизайнерах форм типа MSовского это обычно не делается
нормально (я прошу, только не надо вспоминать anchor'ы).
> А то я уж подумал, что в джаве всего лишь одна кнопка, > которая называется "layout manager".
Ага, одна большая красная кнопка
Здравствуйте, Cyberax, Вы писали:
C>Ну еще и контролы нужны, естественно. Но 99% задач с построением формочек (то есть то что делает form-designer) решаются layout'ами, причем обычно красивее и удобнее.
Никогда не забывай добавлять в таких случаях — ИМХО или для моих задач
C>А вот в дизайнерах форм типа MSовского это обычно не делается нормально (я прошу, только не надо вспоминать anchor'ы).
Для большого проекта лучше сразу покупать какую-нибудь библиотеку контролов. Один тоже в большинстве своём не идеал, но то, что предлагает MS вообще ниже всякого плинтуса.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
MS>>Да и просто дизайнер форм для десктоп-приложений — то еще уродство. Вообще, "пристреливание по пикселам" — это по большому счету все, что требуется от ГУИ-дизайнера.
IT>Не совсем так. Кроме пикселей есть ещё куча свойств, который нужно контролировать. Тот же TabOrder, например, шрифты, цвет, баиндинг.
Ну так это же все чисто визуальные свойства, которые должны быть отделены от кода. Да я даже был бы не против того, чтобы этот дизайнер подковыривал что-то в моем коде, при условии 100% соблюдения первой медицинской заповеди "не навреди". И то, что работоспособность среды разработки напрямую зависит от устойчивости контролов — за такие "архитектурные решения" надо вообще отвинчивать яйца с особым цинизмом. Запусти внутри OnPaint своего контрола бесконечный цикл — студии кирдык.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ведет. Более того, иногда даже hotfixes предоставляет, которые иным способом недоступны. См., например, http://support.microsoft.com/kb/839582/en-us
Это ни о чем не говорит. Вот к этому багу тоже нет публичного хотфикса, но это не означает, что какая то важная информация о самом баге скрыта от глаз наблюдателей, все ответы MS касательно его судьбы в описании бага присутствуют.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, Sinclair, Вы писали:
S>Точно так же и совет "для создания удобного пользовательского интерфейса пригласите специалиста по юзабилити" на практике бесполезен. Более того, я считаю его вредным как минимум для архитекторов, потому что он подразумевает отсутствие необходимости думать самому, и поощряет мысли типа "у нас нет на это денег, а значит хрен с ней с юзабилити". В самом-самом большом проекте, даже типа офиса, уверяю тебя, главный архитектор вовсе не отдает все на откуп "спецам". Архитектор должен сам понимать, что такое юзабилити, иначе его надо гнать в шею, ибо он не сможет внятно поставить задачу юзабилисту.
Главное — именно архитектор принимает решение о балансе юзабилити и затратах труда на него.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, ArtemGorikov, Вы писали:
AG>Можно я вставлю свои пять копеек? McSeem2, когда появится адекватная обертка для AGG под .NET, желательно, максимально близкая по объектной модели и синтаксису к GDI+, тогда его смогут легко использовать простые программисты .NET. Тогда, возможно, даже станет модно заменить им нетовскую обертку GDI+ на альтернативную, как модно заменять IE на Mozilla и кричать "Windows must die" И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.
Ну во-первых, как бы это цинично ни звучало, я не так уж и уверен, что оно надо. Все-таки, чисто софтварный рендеринг, причем даже не оптимизированный под SIMD, лучше рассматривать как академические эксперименты. Просто оказалось, что можно не так уж и плохо использовать в практических приложениях (и уж точно — в областях типа растеризации карт на сервере).
Во-вторых, это просто физически нереально для меня в настоящее время — есть более важные дела, опять же, как бы цинично это ни звучало. Например, работа над тем, как продвинуть подобные алгоритмы в область железа. Но это очень длинная история.
IT wrote: > C>Ну еще и контролы нужны, естественно. Но 99% задач с построением > формочек (то есть то что делает form-designer) решаются layout'ами, > причем обычно красивее и удобнее. > Никогда не забывай добавлять в таких случаях — ИМХО или для моих задач
ОК, буду соблюдать политкорректность
> C>А вот в дизайнерах форм типа MSовского это обычно не делается > нормально (я прошу, только не надо вспоминать anchor'ы). > Для большого проекта лучше сразу покупать какую-нибудь библиотеку > контролов. Один тоже в большинстве своём не идеал, но то, что предлагает > MS вообще ниже всякого плинтуса.
Так проблема не во внешнем виде контролов, а в способе их расположения.
Хотя, если в сторонней библиотеке есть layout'ы...
Здравствуйте, AndrewVK, Вы писали:
AVK>Это ни о чем не говорит. Вот к этому багу тоже нет публичного хотфикса, но это не означает, что какая то важная информация о самом баге скрыта от глаз наблюдателей, все ответы MS касательно его судьбы в описании бага присутствуют.
Суть в том, что не все баги есть в этой базе. Соответственно, отсутствие информации об ошибке в данной базе не позволяет Владу утверждать о том, что его оппонент нечестен.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Вот есть такой сетевой персонаж Рома Воронежский.
Вот его сайт.
А вот из него цитата:
Про юзабилити вот что я могу сказать. Хороший дизайн получается при наличии здравого смысла и желания сделать хорошо. Без этих двух ничего не получится*. Можно выучить наизусть всего Нильсена и Тафта, загадить все форумы цитатами, надеть пиджак и с серьезным лицом рассуждать о юзабилити, получать заказы, срубить все бабло галактики, лечь и умереть. Можно, можно. Галактика, однако, лучше от этого не станет. И если последний факт вас не смущает — учите Нильсена.
* Или получится.
И я с ней на 100% согласен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, ArtemGorikov, Вы писали:
AG>>... Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.
MS>Ну во-первых, как бы это цинично ни звучало, я не так уж и уверен, что оно надо. Все-таки, чисто софтварный рендеринг, причем даже не оптимизированный под SIMD, лучше рассматривать как академические эксперименты. Просто оказалось, что можно не так уж и плохо использовать в практических приложениях (и уж точно — в областях типа растеризации карт на сервере).
Не надо скромничать. Штука действительно полезная, по качеству картинки лучше чем GDI+ а по скорости сравнимая — в чем-то быстрее, в чем-то медленнее. Чтобы эта либа пошла в массы, она должна иметь нормальный интерфейс, лучше всего — похожий на GDI+, под C++ и .NET. Только не надо пытаться повторить FlatAPI GDI+ — это INHO никому не надо.
MS>Во-вторых, это просто физически нереально для меня в настоящее время — есть более важные дела, опять же, как бы цинично это ни звучало. Например, работа над тем, как продвинуть подобные алгоритмы в область железа. Но это очень длинная история.
Ну было же время написать этого зверя? Если к нему добавить полноценную обертку, то можно значительно увеличить число пользователей.
MS>В-третьих, есть нечто такое, причем не одно: MS>1. http://www.rsdn.ru/Forum/Message.aspx?mid=1582093&only=1
MS>2. AGGPlus, http://www.point.com.mk/aggplus/ MS>3. http://antigrain.com/stuff/Agg2D.zip. Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.
И все мимо цели: AGGPlus начато, но не доделано, и обертки нетовской там нет. А если есть обертка нетовская, как в здесь , то это вообще не совместимый с GDI+ интерфейс.
MS>Ну а уж сделать враппер для .Net на MC++ — не сложно.
Не сложно. Но гораздо лучше, когда он уже есть и совместим со стандартом de-facto — чтобы осталось только переключить графику с GDI+ на AGG.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Не надо скромничать. Штука действительно полезная, по качеству картинки лучше чем GDI+ а по скорости сравнимая — в чем-то быстрее, в чем-то медленнее. Чтобы эта либа пошла в массы, она должна иметь нормальный интерфейс, лучше всего — похожий на GDI+, под C++ и .NET. Только не надо пытаться повторить FlatAPI GDI+ — это INHO никому не надо.
Как раз, если воспроизвести FlatAPI, то можно просто-напрсто взять .h файлы GDI+. Но дело даже не в этом. Сама концепция GDI+ является на мой взгляд ужасно непрактичной, неудобной и ограниченной. Не надо его повторять — это неблагодарная работа. "Карандаши" и "кисти" это какой-то неестественный изврат, намешаны в одну кучу фундаментально разные понятия. И я не вижу особого смысла в совместимости. Если проект состоит из 20 мег исходников и по всему коду натыканы вызовы GDI+, то это плохой проект и ему ни какие эмуляции не помогут. Для таких случаев надо не просто эмулировать GDI+, а в точности воспроизводить все его поведение, включая глюки. Иначе где-нибудь, чего-нибудь да отъедет. Это очень неблагодарная работа и я ей заниматься не хочу. Ну а если вся графическая часть сосредоточена в небольшом файле-обертке, кил на 40, то портировать ее на другую библиотеку (хоть на OpenGL) не составляет труда.
Концепция API (или GDI) нового поколения мне представляется несколько иначе.
1. Надо вернуться к традиционной stateful модели (SetFillColor()/DrawPolygon()/etc) взамен неудачной концепции кистей и прочего. Фактически, в GDI+ хотели сделать класс Graphics как stateless, но получилась машанина — трансформации у нас stateful (Rotate, Scale, etc), а использование кистей и карандашей — stateless.
2. Приделать механизм автоматического восстановления состояния. Типа BeginSessoin() добавляет некий entry в стек, EndSession() восстанавливает все изменившиеся после BeginSessoin() параметры. Эти вызовы могут быть вложенными. Для автоматизации вызовов делается простейший scope guard (в C# — using) — очень похоже на SVG или XAML.
3. Возможность формировать собственные векторные конвейеры. Например, Path->AffineTransformer->CurveFlattener->Stroker->PerspectiveTransformer->Clipper->Renderer. Все это должно быть доступно динамически, в run-time.
4. Аналогично — растровые конвейеры, например, Rasterizer->Gradient->AlphaMask->FrameBuffer.
Фактически, все конвейеры в GDI+, Java2D и прочих, жестко закодированы, за счет чего получается огромный объем кода типа switch/case с изначально ограниченной функциональностью. Например, если взять некие анизотропные преобразования (scale(0.5,2.0)), то результат рисования линии будет сильно зависеть от того, когда эти преобразования используются — до строкера или после. А управлять этим в GDI+ нельзя.
AG>Ну было же время написать этого зверя? Если к нему добавить полноценную обертку, то можно значительно увеличить число пользователей.
Было, теперь стало меньше. Рост — это вполне естественный процесс. Сейчас я работаю над версией 2.4, которая будет включать растеризацию Flash. Мне представляется это более перспективным.
AG>Не сложно. Но гораздо лучше, когда он уже есть и совместим со стандартом de-facto — чтобы осталось только переключить графику с GDI+ на AGG.
Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Было, теперь стало меньше. Рост — это вполне естественный процесс. Сейчас я работаю над версией 2.4, которая будет включать растеризацию Flash. Мне представляется это более перспективным.
Это интересно. Но тут уже вопрос: а зачем сообществу программистов растеризация Flash? Если говорить о популярности библиотеки, то IMHO на ее популярность это никак не повлияет.
AG>>Не сложно. Но гораздо лучше, когда он уже есть и совместим со стандартом de-facto — чтобы осталось только переключить графику с GDI+ на AGG.
MS>Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.
Странно... мне совсем не показалось, что GDI+ ограничен в интерфейсе. Довольно-таки простая в использовании либа, правда с кучей нареканий по поводу качества картинки и вообще контроля за процессом рисования — к примеру, у меня она рисовала довольно странного вида линии со стилем PS_DOT — как она масштабировала их толщину и расстояние м/д точками, я не понял. Ну и ее еще нельзя залинковать в модуль, а в моем случае было очень желательно ограничить конечное число модулей до 1, т.е. никаких дополнительных dll-к нести с собой нельзя. Зато GDI+ прекрасно совместима с GDI, т.е. принимает ее настройки масштабирования и все делает сама, не обременяя пользователя деталями реализации.
Если нам не помогут, то мы тоже никого не пощадим.
И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.
1.1.4 stable rev. 510
