LINUX.ORG.RU

Mono Beta 3 has been released


0

0

Ну вот, не прошло и пол месяца - уже третья бетта. С такии темпами мы уже скоро получим релиз. Следующий шаг уже к 1.4 c полной поддержкой WinForms, а сейчас только чере wine!

>>> Подробности



Проверено: Demetrio ()

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

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от Selecter

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

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

anonymous
()
Ответ на: комментарий от Selecter

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

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

Puzan ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

bc
() автор топика
Ответ на: комментарий от bc

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

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

anonymous
()
Ответ на: комментарий от bc

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

eXOR ★★★★★
()
Ответ на: комментарий от Selecter

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

eXOR ★★★★★
()
Ответ на: комментарий от bc

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

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


anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от int19h

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

Eugene_Korobko
()
Ответ на: комментарий от Eugene_Korobko

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

anonymous
()
Ответ на: комментарий от Eugene_Korobko

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

int19h ★★★★
()
Ответ на: комментарий от anonymous

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

t0r
()
Ответ на: комментарий от t0r

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

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

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

eXOR ★★★★★
()

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


ANDI ★★
()
Ответ на: комментарий от XCHG

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

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

Puzan ★★★★★
()
Ответ на: комментарий от eXOR

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

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

anonymous
()
Ответ на: комментарий от Puzan

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


XCHG
()
Ответ на: комментарий от anonymous

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

Eugene_Korobko
()
Ответ на: комментарий от Eugene_Korobko

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

eXOR ★★★★★
()
Ответ на: комментарий от eXOR

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

eXOR ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

int19h ★★★★
()
Ответ на: комментарий от int19h

> дебри API

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

int19h ★★★★
()
Ответ на: комментарий от anonymous

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

bc
() автор топика
Ответ на: комментарий от bc

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

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

int19h ★★★★
()
Ответ на: комментарий от int19h

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

eXOR ★★★★★
()
Ответ на: комментарий от int19h

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

eXOR ★★★★★
()
Ответ на: комментарий от int19h

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

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

eRazor ★★★
()
Ответ на: комментарий от eRazor

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

eXOR ★★★★★
()
Ответ на: комментарий от eRazor

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

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

anonymous
()
Ответ на: комментарий от eXOR

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

eRazor ★★★
()
Ответ на: комментарий от eRazor

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

eXOR ★★★★★
()
Ответ на: комментарий от int19h

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

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

gelios
()
Ответ на: комментарий от eRazor

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

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

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

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

int19h ★★★★
()
Ответ на: комментарий от gelios

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

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

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

int19h ★★★★
()
Ответ на: комментарий от eRazor

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

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

int19h ★★★★
()
Ответ на: комментарий от eRazor

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

anonymous
()
Ответ на: комментарий от anonymous

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

eXOR ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

int19h ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.