Mono Beta 3 has been released

> С такии темпами мы уже скоро получим релиз

ах вот как релизы делаются, Каждую неделю по бете =) Скоро правка комментариев будет новой версией называтся примечательно - IE выходит 1 раз в 2 года, мозилла и ко - каждый месяц =) А функциональность - не очень.

Не лезь в девелоперское дело!

Насколько я знаю, ПОЛНАЯ поддержка WinForms всегда будет ТОЛЬКО через wine. Они собираются дополнительно к wine версии делать еще и gtk-версию WinForms, но с урезанным функционалом - многие приложения, написанные на Windows версии .NET, работать не будут.

Не будут? Тогда нечего вообще затевать разработку mono.

>Не будут? Тогда нечего вообще затевать разработку mono.

Реализовать не очень удачную концепцию оконных сообщений Windows с помощью Gtk сложно, так что претензии не к разработчикам.

> Тогда нечего вообще затевать разработку mono.

Делать им нечего...

.NET - это не только WinForms ;-). Это еще и ASP+ и GTK#. :-).

ASP вообще что-то далёкое - не для нормальных людей.

>Насколько я знаю, ПОЛНАЯ поддержка WinForms всегда будет ТОЛЬКО через wine.

Спецификация WinForms слишком уж ориентированна на WIN32 API (привязана к)

Неудачную аритектуры WIN32 сложно реализовать с помощью gtk, особенно учитывая, что gtk более высокоуровневый

А ты на чистом Gtk прогал? Да, различия есть, но небольшие.... .NET более высокоуровневая среда - и нет ни какой раницы, как она будет реализована, на Qt, Gtk или Win

>А ты на чистом Gtk прогал? Да, различия есть, но небольшие.... .NET более высокоуровневая среда - и нет ни какой раницы, как она будет реализована, на Qt, Gtk или Win

Между чем различия небольшие? Между Gtk и WinAPI??? Ну-ну. Во первых Gtk нет понятия оконной функции, цикла оконных сообщений и пр. А в .NET отголоски этого подхода имеются, взять хотя бы WndProc в Windows.Forms.Form. И как ты предлагаешь прикрутить Windows.Forms к Gtk без геморроя. То, что .NET уровнем выше ничего не изменит - концептуальный подход все-равно тот же.

> А ты на чистом Gtk прогал?
GTK или GDK? И чем отличается чистый от грязного? :-).

> ASP вообще что-то далёкое - не для нормальных людей.
ASP+ != ASP :-). А JSP тоже только для ненормальных? ;-).

>А ты на чистом Gtk прогал? Да, различия есть, но небольшие....

Приходилось .....
Не такие уж и маленькие различия c WIN API :):):):)
Можно было бы сказать, что у motif и gtk схожие концепции ...

Воэможность вызова в Winforms нативных фунций win api уже есть полная жопа,
для использования Winforms в написании кроссплатформенных приложений ...

Достаточно сказать, что в "высокоуровневых" классах WinForms есть функция WndProc...

В QT в классе QWidget есть метод event, который суть та же WndProc. Но это не мешает мультиплатформенности. Наличие оконной функции - вполне нормальное явление.

короче всё понятно - будет кривая резализация .NET под линукс в виде mono, которую использовать в серьёзной работе будет не реально. говно в общем. java рулит :)

Да, но этот WndProc завязан на специфические WinAPI-типы вроде MSG.

.NET WinForms как было г. так и осталось...
http://www.joelonsoftware.com/articles/APIWar.html

Не пизди. Net наверняка станет популярнее явы для написания гуев, да и asp.net удобнее jsp. Одно точно ясно: реализация net под фри юниксы заставит сан изменить лицензию на гнушную.

2 t0r:
> Не пизди. Net наверняка станет популярнее явы для написания гуев
Да уж куда уж... 3 года с момента выхода, а где хоть что-нибудь на .NET написанное из гуёвин? Проблема с .NET - это непереносимость WinForms... значит WinForms отсыхает... GTK# - вполне может быть и вытащит .NET... но уж никак не WinForms... хе хе...

> да и asp.net удобнее jsp
Хе... ну-кась ну-кась... чем это он удобнее ;-).

>Одно точно ясно: реализация net под фри юниксы заставит сан изменить
>лицензию на гнушную.
Ога... за три года не заставила, а тут вдруг пришел tOr и всех построил ;-).

Половина .NET запатентована. Как после этого можно вообще серьезно обсуждать возможность использования mono?

Говоришь лицензии на жабу не изменят? Ну так сдохнут! Сдо-о-о-хнут. Р.И.П.

> Говоришь лицензии на жабу не изменят? Ну так сдохнут! Сдо-о-о-хнут. Р.И.П.

Может объяснишь популярно зачем яву на ГНУ переводить? П..деть все горазды, а объективных причин никто сказать не может. Ламерьё.

> Может объяснишь популярно зачем яву на ГНУ переводить? Гм ;-). Видать: "чтобы було" ;-)))

>Наличие оконной функции - вполне нормальное явление

Да, блин, но только ж в MS это как всегда доведено до маразма, когда, например, нужно создавать невидимые окошки, которые отлавливают события, чтобы работала какая-нибудь хрень типа тамошних сокетов или TWAIN и т.д. И это блин, приходится делать в либах, которые к гую никакого отношения не имеют.

Уже хотя бы по тому, что для них жаба убыточна, а их будущее туманно. Немного напрашивается аналогия
со стар офисом: пришлось отдать в опенсорс чтобы хоть чтото начало двигатся. Тут ситуация другая, но
тем не мение. Как ни странно, но в опенсорсе именно ГНУТЫЙ софт развивается быстрее всего.
Хотя ИМХО будет лучше если они не откроют ни жабы ни солярки - усилия тех, кто что то делает не будут
тратится на херню - моно и линукс только выиграют.

В винде окно было больше чем окно. Вернее сказать. окно было частным случаем (хотя и самым распространённым) специального объекта, обеспечивающего работу ассинхронных вызовов. В .NET этого уже нет. В целом, .NET с сугубо технической стороны явно лучше, чам ява.

> .NET с сугубо технической стороны явно лучше, чам ява.
Можно поконкретнее? :-). Пока все споры заканчивались тем, что .NET делает a,b и c так же как java, d,d и f чуть-чуть по-другому... в целом платформа еще очень зеленая, но уже успевшая разочаровать разработчиков и манагеров ;-).

>.NET WinForms как было г. так и осталось... >http://www.joelonsoftware.com/articles/APIWar.html

Joel дяденька конечно мудрый. Однако многие его заключения весьма спорны, как впрочем и Ваши. .NET WinForms не говно уже по тому, что оно очень близко к Win API и поэтому работает более эффективно ( я думаю факт безспорный ) чем скажем SWING-и *** НА Windows ***. Т.е. свою задачу вполне решает. Кому интересно, что это не работает на Linux? только не Microsoft-у и не разработчикам под Windows.

>Не пизди. Net наверняка станет популярнее явы для написания гуев

Это правда. Только нужно добавлять ПОД Windows.

> Это правда. Только нужно добавлять ПОД Windows.
:-). Хех... ну под винду и альтернатив-то нету...

> .NET WinForms не говно уже по тому, что оно очень близко к Win API и поэтому работает более эффективно ( я думаю факт безспорный ) чем скажем SWING-и *** НА Windows ***. Т.е. свою задачу вполне решает. Кому интересно, что это не работает на Linux? только не Microsoft-у и не разработчикам под Windows.

Говорю как разработчик на C# под винду. Если ты мне скажешь, как в нем сделать owner-draw-ListView, не скатываясь в дебри API, или покажешь любой другой способ запихать в одну из колонок списка прогрессбар (а-ля ReGet), без переписывания ListView с нуля - с меня пиво.

Кстати, в Qt это делается на раз...

> дебри API

Имелся в виду, разумеется, Win32 API

Тогда объесни чем Java и .NET различаются, в концепциях. Многие, кто прогает на Jave и переходят на .NET в первое время разницы вообще не видят, только лишь потом, начинаю понимать где плюсы, а где минусы!!!

> Тогда объесни чем Java и .NET различаются, в концепциях.

Как пример - в .NET (и в WinForms, и в ASP.NET) практически начисто отсутствует такое понятие, как MVC. То есть отделять UI-код от логики приходится ручками, и оччень топорно получается... а уж про нормальное разделение HTML-отображения и кода в ASP.NET можно забыть.

2 int19h:
>а уж про нормальное разделение HTML-отображения и кода в ASP.NET можно
> забыть.
Гм... а в чем проблема с codebehind?

>Если ты мне скажешь, как в нем сделать owner-draw-ListView, не
>скатываясь в дебри API, или покажешь любой другой способ запихать в
>одну из колонок списка прогрессбар (а-ля ReGet), без переписывания
>ListView с нуля - с меня пиво.
Кстати реальная проблема... с MFC та же песня.. :-(.

>Говорю как разработчик на C# под винду. Если ты мне скажешь, как в нем сделать owner-draw-ListView, не скатываясь в дебри API,

Мне не даёт покоя этот твой пример. Ты уже приводил его. Данный пример НЕ является контрпримером того, что Ц-шарп не решает поставленых задач. Зачем ты его приводишь? Сложная нестандартная отрисовка на гуе -- в топку. Ну приведи пример мне, где функциональность приложения изменилась пропорционально трудозатратам на рисовательство гуя? Возьмусь утверждать, что в 99% случаев задач, которые решают программисты изготавливающие "табуретки", нестандартное рисовательство -- бесмысленная потеря рабочего времени. Пока мне опыт моей работы говорит, что ничего хорошего из увлечения красивым гуем не получалось. Гуй вообще должен сесть дизайнер нарисовать из стандартного набора контролов. Гораздо лучше получится результат, чем изобретение самопальных украшательств. Неужели в твое задачи, без owner-draw на ListViwe не обойтись? Даже если так, это ВЫРОЖДЕНЫЙ случай.

> Неужели в твое задачи, без owner-draw на ListViwe не обойтись? Даже
>если так, это ВЫРОЖДЕНЫЙ случай.
Необходимость в нестандартных контролах возникает тогда, когда гуйня - это 80% приложения... редакторы, браузеры, всякие файл манагеры итд итп...

>естандартное рисовательство -- бесмысленная потеря рабочего времени.

Блин! ЗОЛОТЫЕ СЛОВА!

Ну а теперь посчитай, КАКОЙ ПРОЦЕНТ они составляют? И в этих приложениях тем более проф. дизайнер должен этим заниматься.

>Ну а теперь посчитай, КАКОЙ ПРОЦЕНТ они составляют?
0 целых $уй десятых, но сталкиваться приходилось уже дважды :-). И каждый раз дизайнера не было :-\...

2int19h
>Говорю как разработчик на C# под винду. Если ты мне скажешь, как в нем
>сделать owner-draw-ListView, не скатываясь в дебри API, или покажешь
>любой другой способ запихать в одну из колонок списка прогрессбар (а-ля
>ReGet), без переписывания ListView с нуля

Глянь в System.Windows.Forms.UserControl. Это пустой контрол, на базе
которого можно сделать свой и не нужно лезть в дебри API. В документации
Framework даже есть примеры.

> Мне не даёт покоя этот твой пример. Ты уже приводил его. Данный пример НЕ является контрпримером того, что Ц-шарп не решает поставленых задач. Зачем ты его приводишь? Сложная нестандартная отрисовка на гуе -- в топку.

Это ты скажешь заказчику. И кстати я вполне могу его понять - ну вот увидел человек ReGet, понравилось, как там очередь задач сделана... а прогрессбар в списке - это уже давно вполне стандартный контрол (см. практически любой download manager, даже оперовский интегренный и тот такую фишку имеет).

Да, а что насчет TreeListView? Тоже, скажешь, нестандартная отрисовка? Ну-ну...

И еще напомню про MVC (точнее, про его отсутствие). Это, по-вашему, тоже в топку?

> Глянь в System.Windows.Forms.UserControl. Это пустой контрол, на базе которого можно сделать свой и не нужно лезть в дебри API

Это ты предлагаешь переписать с нуля целиком весь ListView. Чего я как раз просил НЕ предлагать, по вполне понятным причинам. А то так лучше бы весь WinForms переписать (что в принципе уже сделано, и называется Gtk#).

Справедливости ради: в следующем .NET Framework будут и owner-drawn списки, и ListTreeView. Но вот чего там не будет? Нервно жду, когда вляпаюсь в очередные грабли...

> Ц-шарп не решает поставленых задач

Кстати речь я вел не о C#, а о WinForms. C# как язык мне очень нравится (определенно больше явы). dotNET как платформа - местами. WinForms и ASP.NET - совсем нет.

это кстати одно из ключевых отличий гуй програм win/lin, в виндах часто любят виджеты адаптировать под программу (delphi компоненты самый яркий пример), в линуксе гуи в основном аскетично-стандартные, в виндах любят извернуться, не всегда уместно, но часто всё же от этого полезнее/удобнее.. хотя с точки зрения программера-трудяги - потеря времени.. но так можно дойти и до того, что и гуй потеря времени, всё можно сделать и через CLI

> в виндах любят извернуться, не всегда уместно,
более 50ти разных тем для QT и столько же для GTK+ это по твоему не изврат? А вообще в QT/GTK прилепить к виджету нужную функциональность проще... Ну и в добавок... про стандартные контролы.. в винде они все _одного_типа_ а в linux это GTK+ / QT / Mozilla / Motif и др... вот что действительно потеря времени...

> в линуксе гуи в основном аскетично-стандартные, в виндах любят извернуться, не всегда уместно

Есть такой момент. Но! Если за "стандартные гуи" считать Qt и Gtk, то они предоставляют куда большую гибкость в этом вопросе, и "извернуться" куда легче (вплоть до того, что это и извратом не назовешь уже).

А WinForms мне напоминает Delphi и VB - такой же инструмент для "тяп-ляп"-программирования. Это когда садимся писать с места в карьер (безо всяких там анализов и диаграмм), накидываем сначала гуй, а потом к нему начинаем привешивать код с логикой. Последствия вполне очевидны: мешанина гуя и бизнес-логики, в которой без стопки не разобраться, синдром "магической кнопки" в худшем своем проявлении... короче, читайте Bitter Java - там оно все описано =) Не то что бы та же жаба от этого застрахована, нет... но в ней есть все средства для предотвращения таких дел, и в любой книжке по яве десять раз повторяется: "вот так - НЕ ДЕЛАТЬ!". До многих доходит. А вы книжки самого майкрософта по .NET видели? (скажем, для подготовки к сертификации MCAD/MCSD) Там когда дело доходит до примеров, такой тихий ужас, что я уже не удивляюсь очевидным грубым ошибкам в дизайне BCL...