Замена WPF для desktopa под С#
Здравствуйте, интересует следующий вопрос. Если адекватная/современная замена WPFа для desktopa под С# ? Windows forms в топку. Ищу что то на подобии QML или (в идеале) GUI на связке html5/css/javascript.
Буду очень признателен за хорошие идеи :) .
56 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівБуду пилить под desktop на С#/WPF, для Metro С#/XALM, а для web оставлю html5/css/javascript. Спасибо всем.
под Win или решить какую-то задачу?
Там был standalone Tomcat где крутились jsp-шки, и был клиент ко всему этому на Delphi + Gecko Engine(Firefox).
Собственно что вам нужно. Запустить на клиенте локальный веб-сервер на C#, который принимает пакеты только с локалхост. А далее как для веба. webserver.codeplex.com
Как вариант — можно захостить веб-сервис под IIS.
Ну и есть HTA, но эта технология мертва. Будет её обновление и воскрешение в Win8.
никогда не думали, что десктопных приложений просто не будет?
Мне это кажется маловероятным
ну сейчас на них спрос только падает
И будет падать. Но ОС совсем без десктопных приложений представить пока сложно. ChromeOS не в счёт ибо неюзабельна совсем.
Скорее исчезнут, или основательно изменятся сами понятия — десктопное и веб.
Когда поддержка инфраструктуры запуска приложений станет прозрачной для программиста — как будет отличать десктопное это приложение или нет?
Пользователь что-то кликнул — запускается приложение. Часть его кода тянется с другого устройства, часть — с его же. А может и все оно тянется откуда то. А может все с его устройства. Пользователь не знает, и его это не беспокоит, он все равно НЕ устанавливает приложение, как сейчас.
Программист будущего когда пишет приложение — тоже не заботится, какая часть будет загружаться с серверов, причем неизвестно каких, по каким протоколам (может жирное по p2p), какая будет кэшироваться, если устройство пользователя позволяет.
Сейчас такое разделение существует только потому что разработчик САМ разделяет серверную и пользовательскую(интерфейсную части). Он САМ вынужден как-то управлять загрузкой, кэшированием для веб-приложения. Это сейчас он вынужден создавать разнообразные API для взаимодействия частей своего приложения.
Примерно как если бы программист десктопного приложения каждый раз сам управлял чтением и записью секторов на пластине жесткого диска, и добавлял код для вычитки из ячеек SSD.
То же и с GUI и WebUI. GUI интерфейс не исчезнет отдельно от WebUI. нынешнее различие исчезнет.
То есть как только исчезнут десктопные приложения, исчезнут и веб-приложения. Будет какая-то другая классификация, или не будет вообще.
С + GTK, ну или C# + GTK, если хочетсо эзотерики то Haskell + GTK
В своё время познакомился с OpenGL, и проработав с этой библиотекой продолжительное время понял- что это вполне хорошая замена тогдашнему GDI. Наверное почти все играли в игрушки- а почти каждая игрушка реализует свои окна, шрифты — вобщем пользовательский UI.
Вот какие преимущества связки OpenGL C++ я вижу:
1. Возможность создавать единный пользовательский UI для различный платформ
2. При наличии видеоподсистемы- практически полная разгрузка ЦП, и обработка UI на видеокарте, как результат повышение производительности.
3 Свобода в реализации требуемых элементов UI (Compiz — хорошее начинание- но ограничено обратной совместимостью)
4 Больше не надо учить «однодневные» библиотеки UI от микрософта и др компаний, которые оказываются в результате жутко тяжеловесные, сырые и недолго живущие.
5. Легкость перехода из «формошлепства» в «геймдев» и обратно.
Недостатки:Высокий порог входа по сравнению с с обычным «формошлепством»
Необходимость обратной совместимости может свести все усилия на нет.
Отсутсвует поддержка подобных идей в лице крупных игроков
ИМХО.
у вас извращённое понимание того, что хорошо, а что плохо. Приложение должно иметь единый интерфейс со средой, в котором оно исполняется.
Ага, как же. OpenGL — всего лишь библиотека на сотню-другую функций.
2) C# + XAML
Да, я об таких возможностях знаю. Весь прикол в том, что я хочу (да и остальные думаю тоже) использовать связку html5/css/javascript + С# напрямую, без XAML :) .
Спс, ситуация окончательно прояснилась.
“How to cook a complete Windows 8 application with HTML5, CSS3 and JavaScript in a week”
blogs.msdn.com/...week-day-0.aspx
Угу, но вот только как так хитро впилить чтоб связка html5/css/javascript могла работать с С# или С++ без XAML и геморроя :) ?
А зачем конкретно нужна часть на C#?
Для стандартных задач есть «App contracts»:
msdn.microsoft.com/...s/hh464906.aspx
Если нужна серверная логика то можно вызывать сервисы. А если совсем оффлайн десктоп приложение то похоже можно и свои эссембли прикрутить:
www.bluemetal.com/...HTML5-2b-C.aspx
www.franksworld.com/...inrt-components
Но если писать на С# то теряется вся потенциальная кросс-платформенность HTML5 приложения. Тогда уже лучше WPF — на нем можно красивее нарисовать.
В том то и проблема, что теперь не знаю зачем он мне вообще :( .
четыре года назад подобные «питання» привели к тому, что я бросил десктоп и ушел в веб, заодно и на линукс пересел :)
Он, вроде, как сдох (уволили всю команду).
Ну вот в вин8 так будет.
Вроде жив, хотят в Qt 5 выпустить qt quick 2.0
Да, но не так как хотелось бы. html5/css/javascript это одно течение, а XAML/C# другое. Я гдето читал, что можно как то в XAML впилить html5, но это извращение.
А не будет ли с этим тотальным HTML 5 рай для искателей дыр в безопасности?
Но, ИМХО, это дополнительный сендбокс, должно только увеличить безопасность и даже стабильность.
1) Зачем вам замена?
2) Зачем вам десктоп?
2. так надо :)
3. WPF в Windows 8 отведена весьма сомнительная роль второго плана
Чем больше я узнаю о Windows 8 тем сильнее мне хочет мигрировать на Linux O_o
ну удачи вам в поиске тогда :)
ага. и писать для него десктопные приложения :) говорят, что очень прибыльно :)
Ёпт, ну можно mobile и web писать. Фишка в том, что silverlight уже убили, WPF следующий. По идее XAML можно трансформировать в HTML и прикрутить С#.
Вот пару ссылок хороших:1. coolthingoftheday.blogspot.com/...evelopment.html
2. magenic.com/...ntPlatform.aspx
А смысл?
Я думаю, подобные мысли посетили очень многих. В своё время писал по Red Hat на C++. ничего сложного в этом нет. В то время под Windows был только VS 6.0. В Linux, по привычке пользовал Midnight Commander c плагинами для подсветки синтаксиса. Сейчас работаю с основном с C#, но похоже надо воскрешать свои знания по С++, т.к. C# узко ограничен Windows,(моно не предлагать) а то что собой представляет 8-ка- уххх, просто нет слов. Я такого потворства еще не видел. Вообщем, моё видение такое- Windows 8 очень подпортит жизнь .Net разработчикам- а поэтому, если думать о будущем- то лучше переходить в Java, С++. Эсть и другие варианты- но как по мне даные инструменты более широко применимы. Просто ИМХО. Я не хочу стратить время на постоянную гонку в изучении новых рюшечек win UI, бороться с их сыростью и тд. Изучать Silverlight-ы, WPF-ы, WinForms-ы которые ровно через2-3 года теряют актуальность, и используются в ооооочень узком кругу бизнеса. ASP.NET похоже единственная более менее успешная вещь на данном поприще. Лучше имеющееся время вложить в более интересное и прибыльное в будущем направлении.
Хотя если нравится политика микрософт в отношении ОС- тогда да C#, C++.
десктопные приложения под юникс используются в очень широком кругу бизнеса
Есть вариант сидеть на С++, но с Qt непонятная хрень творится. Может реально посмотреть в сторону Java ...
Будете вы сидеть на винде и через
Есть только 2 существенные причины почему люди не переходят на Линукс: миф о его сложности и нестабильности, отсутствие современных игр аля Battlefield 3. Достаточно преодолеть хотябы вторую проблему и это будет взрыв.
Ага — примерно как пересесть с 1C на С++. Всего-то пару-тройку книжек по 500 страниц прочесть и будешь все через консоль делать.
интересное сочетание текста коммента и надписи «Lead Software Engineer»
не говорите глупостей. если для вас компьютер медиацентр — то возможно и без разницы. если для вас компьютер с виндой — это инструмент — то вы с нее не слезете в здравом уме по собственной воле
если єто всего лишь инструмент — ничто не остановит от смены «инструмента» на более удобный
кто вам сказал, что для меня это инструмент не наиболее удобный?
а первая да, проблема даже не в сложности (я скажу что многие задачи решаются гораздо проще, особенно troubleshooting ) а в совершенно другом наборе софта (которого довольно много разного для одних и тех же задач, но нужно время что бы выбрать то, что подходит именно вам и решают именно ваши задачи) и «паттернов» использования — которые бывают гораздо удобнее виндовских, но «другие» , ну и часть функционала в винде либо не встречается, либо неудачен, либо доступен только для гиков
вобщем я склонен считать, что тут не человек выбирает ось, а ось человека — если вы подходите к юниксам (вплоть до макоси) то рано или поздно вы на ней окажитесь, если нет — то возникнет миллион причин почему она вам «не понравилась»
Согласен
по-моему автор просто неадекватен. начитался статей на опеннете и теперь мудростью блещет
такова специфика DOU: начинаем с одного, обсуждаем другое, заканчиваем третьим
автор безумен :-D
сам процесс готовки и само нежелание работать с ним :)
То есть даже не пробовали? Понятно.
так вы уточните у человека, от которого вы идею эту подхватили что он имел в виду, когда плохо отзывался о xaml. не исключено, что именно это и тогда html5 вам тоже не подходит
Пробовал, не понравилось. Постоянно было чувство, что работаю с недоhtmlем. И выходя из сообржаения, что xaml only for windows (и может быть брошен MS в любой момент), а html вездесущ, то поневоле приходит понимание, что тратишь время впустую и начинаешь искать возможность заменить xaml htmlем даже если это и невозможно.
вы хотели сказать «переhtmlем»? возможности даже Silverlight в разы превосходят html
MS убил Silverlight в угоду HTML5.
сильверлайт сейчас живее любого линуксового/кроссплатформенного гуи фреймворка