Здравствуйте, VladD2, Вы писали:
VD>На мамом деле скорость разработки для конкретного индивидума определяется скорее его познаниями в конкретных технологиях. Если ты хорошо знаком с Дельфи и посредственно знаешь C#, то конечно для теля скорость (и даже качество) разработки на Дельфи будет выше. Однако для людей одинаково хорошо знакомых с разными технологиями выбор очевиден. И он не в пользу Дельфи. От того Дельфи и дохнет на глазах. Ну, а если сравнить Дельфи с каким-нить Nemerle или F#, то это будет все равно, что сравнение хромой кобылы с автомобилем Мустанг в условиях шоссейной гонки.
Ага, если иметь очень глубокие знания в ASM-e то еще быстрее
VD>Что до библиотек, то их для .NET огромное множество. Больше (но не факт, что лучше) только для Java. Сравнивать их с Дельфевыми библиотеками просто смешно. Найди к примеру, аналог WPF для неуправляемого Дельфи.
А вообще есть аналог WPF не для .NET? Еще бы сказал что нету LINQ для неуправляемых языков
Здравствуйте, VladD2, Вы писали:
AVK>>Идеология построения — MVC, лейауты, малое количество гибких контролов.
VD>Тогда почти все ГУИ-библиотеки имеют много общего .
На практике куда больше библиотек с идеологией VCL/MFC сотоварищи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>На практике куда больше библиотек с идеологией VCL/MFC сотоварищи.
Расскажи по подробнее о ней. А то авторы этих библиотек в один голос утверждают, что использовали MVC.
Причем если VCL еще по организации похожа на ВыньФормс, так как предлагает реализовывать контроллер программисту через события, то вот MFC — это классика MVC.
Реально архитектура WPF сильно отличается. Она скорее ближе к архитектуре 3D-игр. Но конечно по признаку использования паттерна MVC все GUI-библиотеки похожи .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Расскажи по подробнее о ней. А то авторы этих библиотек в один голос утверждают, что использовали MVC.
MVC они предлагают использовать пользователям (о чем ты сам ниже пишешь), а WPF/Swing используют MVC для самих контролов. Можно оторвать модель контрола от представления в MFC? А WPF/Swing можно.
VD>Реально архитектура WPF сильно отличается.
Она, конечно, отличается.
VD> Она скорее ближе к архитектуре 3D-игр.
??? Чем именно она так близка?
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Можно оторвать модель контрола от представления в MFC?
Да там контролы как надстройка сделаны. Так что по умолчанию так оно и есть. Ты бы почитал об MFC.
Я конечно понимаю, что из всех ГУИ библиотек отличных от WPF и WinForms тебе ближе Swing, но это еще не повод, чтобы считать все остальное дыркой от бублика.
VD>>Реально архитектура WPF сильно отличается.
AVK>Она, конечно, отличается.
VD>> Она скорее ближе к архитектуре 3D-игр.
AVK>??? Чем именно она так близка?
Идеологией. На верхнем уровне, мы не реагируем на события и рисуем, а размещаем объекты в сцене, а потом уже кто-то отображает эту сцену на представления. Это конечно тоже MVC, но все же.
Как раз у MFC и Свинга много общего. И там, и там пропагандируется идея абстрактного источника данных. В МФЦ оным является документ.
Ну, а вообще все библиотеки разные. WPF явно особенная. Скорее с ней можно сравнивать разные Макромедия Флэши нежели обычные ГУЕ-вые библиотеки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да там контролы как надстройка сделаны.
Ну и что?
VD> Так что по умолчанию так оно и есть. Ты бы почитал об MFC. Я конечно понимаю, что из всех ГУИ библиотек отличных от WPF и WinForms тебе ближе Swing, но это еще не повод, чтобы считать все остальное дыркой от бублика.
Я не только про нее читал, а еще и писал под нее. И под WPF и Swing тоже. И под OWL, как плюсовую, так и паскалевую. Так что давай не будем обсуждать взаимную квалификацию. а то я вспомню про твои знания WPF и свинга.
AVK>>??? Чем именно она так близка?
VD>Идеологией. На верхнем уровне, мы не реагируем на события и рисуем, а размещаем объекты в сцене, а потом уже кто-то отображает эту сцену на представления.
Это не архитектура всего WPF, это маленький кусочек, ответственный за рендеринг. Причем этот кусочек может быть заменен — первые беты WPF использовали для отрисовки банальный GDI с классической отрисовкой по событию.
В свинге, кстати, тоже нет никаких событий отрисовки на прикладном уровне.
VD>Как раз у MFC и Свинга много общего. И там, и там пропагандируется идея абстрактного источника данных. В МФЦ оным является документ.
Документ это конечно здорово. Но, еще раз — это объект прикладного кода. А в свинге, к примеру, модель можно оторвать от кнопки. Есть контрол кнопка, есть отдельно где угодно ее состояние, есть модель, обеспечивающая взаимодействие этой кнопки с состоянием. MFC же базируется на виндовых нативных контролах, и, если их вообще возможно перековать под такую модель — это будет жутчайший геморой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Я не только про нее читал, а еще и писал под нее. И под WPF и Swing тоже. И под OWL, как плюсовую, так и паскалевую. Так что давай не будем обсуждать взаимную квалификацию. а то я вспомню про твои знания WPF и свинга.
ОК. Тогда поведуй мне зачем нужны классы CView и CDocument если MFC не поддерживает MVC.
AVK>Это не архитектура всего WPF, это маленький кусочек, ответственный за рендеринг.
Вот этот маленький кусочек весьма важное архитекрутное отличие определяющиее много чего.
А то что что-то там на МВЦ основано, так оно все на нем. Пока ничего более умного не придумали.
AVK>Причем этот кусочек может быть заменен — первые беты WPF использовали для отрисовки банальный GDI с классической отрисовкой по событию.
Думаю, что после этой замены (если она вообще возможна) смысла в WPF не будет как класс.
AVK>В свинге, кстати, тоже нет никаких событий отрисовки на прикладном уровне.
Я сам видел код кастом-отрисовки.
VD>>Как раз у MFC и Свинга много общего. И там, и там пропагандируется идея абстрактного источника данных. В МФЦ оным является документ.
AVK>Документ это конечно здорово. Но, еще раз — это объект прикладного кода. А в свинге, к примеру, модель можно оторвать от кнопки.
MFC не для кнопок делалась. Она делалась для разработки приложений а-ля Офис. В то время модно было все наследовать от единого базовго класс. Вот документ и был им. А к представлению он никак не привязан. Там в этом контексте все впорядке.
AVK>Есть контрол кнопка, есть отдельно где угодно ее состояние, есть модель, обеспечивающая взаимодействие этой кнопки с состоянием. MFC же базируется на виндовых нативных контролах, и, если их вообще возможно перековать под такую модель — это будет жутчайший геморой.
МфЦ как раз имеет четкое отделение модели от представления см. выше. Кнопки там вообще сделали от балды и далеко не в первой версии. И кнопки эти всего лишь обертка над комон-контролами винды. Отсюда и поведение. Но ты волен сделать сам представления и документ которое в них будет отображаться. При этом все будет очень даже отвязанной. Все что нужно для этого в МФЦ есть.
Кстати, модель Свинга не очень то соответствует как раз WPF-фу который предлагает заполнять контентом те самые контролы. Там скорее больше аналогий с ВиньФормсами. Тоже есть датабиндиг и т.п. А заложить данные прямо в кнопку мне там никто не помешает. В Свинге с этим вроде бы сложнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Господа, очень боюсь показаться невежливым, но не могли бы вы остановиться в перечислении схожих и отличных черт в WPF, MFC, Swing, OWL, etc? Не сомневаюсь, что вы отлично в них разбираетесь. Дело в том, что подписчикам на ветку приходят уведомления о новых сообщениях, а там — оффтопик.
Впрочем, если есть какие-нибудь интересные ссылки про WPF, буду очень благодарен. Причём лучше более обзорные статьи для новичков, но можно и серьёзные.
Здравствуйте, Qbit86, Вы писали:
Q>Господа, очень боюсь показаться невежливым, но не могли бы вы остановиться в перечислении схожих и отличных черт в WPF, MFC, Swing, OWL, etc? Не сомневаюсь, что вы отлично в них разбираетесь. Дело в том, что подписчикам на ветку приходят уведомления о новых сообщениях, а там — оффтопик.
Здравствуйте, VladD2, Вы писали:
AVK>>Я не только про нее читал, а еще и писал под нее. И под WPF и Swing тоже. И под OWL, как плюсовую, так и паскалевую. Так что давай не будем обсуждать взаимную квалификацию. а то я вспомню про твои знания WPF и свинга.
VD>ОК. Тогда поведуй мне зачем нужны классы CView и CDocument если MFC не поддерживает MVC.
Еще раз по буквам — я нигде не писал, что MFC не поддерживает MVC, я написал что сами контролы не устроены как MVC.
AVK>>Это не архитектура всего WPF, это маленький кусочек, ответственный за рендеринг.
VD>Вот этот маленький кусочек весьма важное архитекрутное отличие определяющиее много чего.
Зарадибога. Только помимо рендеринга есть еще масса аспектов. Я говорил о модели контролов (то, что составляет собственно PresentationFramework, а не базовые уровни навроде composition engine ии оберток вокруг нее). Если сравнивать с классическими GUI библиотеками, то есть функционал, реализуемый GDI и user32, а есть объектные обертки, которые собственно библиотека. PresentationFramework это грубый аналог второго, а composition engine и механика, генерящая raw events — первого.
AVK>>Причем этот кусочек может быть заменен — первые беты WPF использовали для отрисовки банальный GDI с классической отрисовкой по событию.
VD>Думаю, что после этой замены (если она вообще возможна) смысла в WPF не будет как класс.
Как сказать.
AVK>>В свинге, кстати, тоже нет никаких событий отрисовки на прикладном уровне.
VD>Я сам видел код кастом-отрисовки.
Ну, я тебе и в WPF могу показать такое. Берем рефлектор, открываем PresentationFramework.dll, смотрим, ну пусть System.Windows.Shapes.Ellipse, метод OnRender.
protected override void OnRender(DrawingContext drawingContext)
{
if (!this._rect.IsEmpty)
{
Pen pen = base.GetPen();
drawingContext.DrawGeometry(base.Fill, pen, new EllipseGeometry(this._rect));
}
}
Годится?
VD>MFC не для кнопок делалась.
VD>МфЦ как раз имеет четкое отделение модели от представления см. выше.
Читай внимательно что я пишу.
VD>Но ты волен сделать сам представления и документ которое в них будет отображаться.
В тысячный раз — документ это сущность прикладного кода, я говорю про сущности самой библиотеки.
VD>Кстати, модель Свинга не очень то соответствует как раз WPF-фу который предлагает заполнять контентом те самые контролы.
То, что в WPF называется Content, в свинге называется Model. Существенная разница лишь в том, что у контролов WPF этот контент нетипизированный и они в рантайме пытаются интерпретировать все гавно, которое туда подпихнут, а в свинге модель описана строго типизированными интерфейсами.
VD> Там скорее больше аналогий с ВиньФормсами. Тоже есть датабиндиг
Офигеть. В WPF тоже data binding есть собственный, не знал?
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>В свинге, кстати, тоже нет никаких событий отрисовки на прикладном уровне.
VD>>Я сам видел код кастом-отрисовки.
AVK>Ну, я тебе и в WPF могу показать такое. Берем рефлектор, открываем PresentationFramework.dll, смотрим, ну пусть System.Windows.Shapes.Ellipse, метод OnRender. AVK>
Вообще-то это не отрисовка. Это её декларация, с которой потом можно ещё понаделать много разных трансформаций. Отрисовка в WPF — это скорее где-то в System.Windows.Graphics.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Вообще-то это не отрисовка. Это её декларация
Не, это именно отрисовка. Декларация там нарисовывается, когда эта отрисовка преобразуется в набор узлов для передачи в конвеер composition engine. А на прикладном уровне, что WPFных рендерер, что GDI+, принципиального отличия нет.
Вот реальная картинка контролов, собираемая из шейпов и примитивов, вот она да, она абсолютно декларативна, но это уже совсем другой уровень.
Чтобы не продолжать этот спор, сразу скажу — модель рисования WPF безусловно на свинг не похожа.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, это именно отрисовка.
DrawingContext в принципе не рисует. Он только создаёт набор рисовальных инструкций. Их можно с таким же успехом задать и в XAML.
AVK>Декларация там нарисовывается, когда эта отрисовка преобразуется в набор узлов для передачи в конвеер composition engine. А на прикладном уровне, что WPFных рендерер, что GDI+, принципиального отличия нет.
Принципиальное отличие как раз имеется. Приведённый тобой метод UIElement.OnRender ничего сам не рисует, он генерирует инструкции, о чём недвусмысленно написано в документации. Далее такой контрол можно подвергать всевозможным трансформациям, анимациям и прочим ациям.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
ЗЫ Когда-то инсталятор Oracle был на Tcl/Tk. Работал и не жужжал. Когда попёрла java (~1998) инсталятор переписали и мало того, что возникла куча багов, так оказалось, что инсталятору памяти нужно больше, чем самой СУБД для работы. Т.е. в требованиях к СУБД стояло толи 32 толи 48, а инсталятору нужно было более 64Мб.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Lloyd, Вы писали:
L>>А что между ними общего?
AVK>Идеология построения — MVC, лейауты, малое количество гибких контролов.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, Lloyd, Вы писали:
L>>>А что между ними общего?
AVK>>Идеология построения — MVC, лейауты, малое количество гибких контролов.
FR>Угу, практически краткое описание TK