Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Когда нужно было опенсорсить, чтобы поезд не пропустить (почему именно тогда)?
До того момента, когда стали популярны реактивные js-фреймворки, электроны и прочие QtQuick. В общем очередной легаси-фреймворк для легаси-языка, используемого в легаси-проектах. От опенсорсинга будет ни жарко ни холодно.
T>>аргумент очень простой: пусть цветут все цветы, T>>на WPF написана такая куча приложений, что переписывание их на скриптe будет длиться десятилетия и будет стоить триллионы, T>>да и то не факт, что получится что-то близко сопоставимое
CS>GitHub Windows Desktop Client был написан на WPF, после того (или во время) как MS купила GitHub этот клиент переписан на Electron.
не видел ни того ни другого, у меня на памяти другой пример: после того, как скайп для десктопа переписали на электроне, новая версия стала полным говном
но если у кого есть стопитьсот тысяч кумаров, которых нечем занять, то почему бы и нет?
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, Эйнсток Файр, Вы писали:
_>WPF — скорее всего RIP, используется только в старючих корпоративных проектах 2008-2010 годов. Как бывший разработчик в том силе на WPF — могу подтвердить, то новые проекты на WPF ни кто не делает.
Вот прямо сейчас начинаю новый проект.
В финансах wpf везде. А это основной потребитель ИТ услуг
_>Просто на js фреймворке + bootstrap можно сделать UI, который ничем не будет уступать WPF.
Мне нравится ваш энтузиазм.
Возьмётесь на нем сделать GUI трейдинговой системы ? С соответствующими требованиями к надёжности и быстродействию
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, white_znake, Вы писали:
НС>>А вот то что для html нельзя сделать нормальный визуальный редактор — еще более мощный минус
_>Визуальных редакторов html — до фига.
И все как один — уродские.
_>Чем тебе не нравятся существующие?
Тем что они генерят кривой html. Нормальный html написать — даже для человека серьезная задача, требующая большого и специфического опыта, и правильного мышления. WPF в этом плане сильно дружелюбнее.
Здравствуйте, Shmj, Вы писали:
S>На самом деле рано кричите "гоп". Еще не ясно чья возьмет. Спешите. Вот уж WebAssembly и Blazor на подходе. Евангелисты пишут что JS-фреймворки — это поезд, который движется к пропасти. Возможно так и есть.
JS фремворк меняется за предсказуемое время. Это не проблема. Фремворки дохнут. Но точно так же передохли сотни UI библиотек для доса, виндовса и линукса. В живых осталось не так уж и много.
Последние проекты для плюсов, о которых я слышал, представляли собой интеграцию c V8, написание плагинов к Cordova, Android, модулей к node и кое какие приседания с nginx и lua.
Т.е. примерно так — часть ушла в node или unity, часть ушла в джаву, часть — в эмбеддед разработку на жесточайшем Си-без-плюсов.
Причин много на самом деле
1 АПИ системы и браузера повзрослели и для большинства приложений больше не нужно лазить в кернел-мод за данными от драйвера.
2 Если раньше большинство проектов это были довольно сложные и тяжелы приложения, то сейчас вместо этого миллионы прикладных вещей, которые довольно легко можно запилить в браузере.
3 В данный момент JS это единственное внятно работающее кроссплатформенное решение. "qt,qt,qt" @ из подвала
4 С++ слишком сложен. Пока вырастет начинающий с++ разработчик, бухгалтер без образования успевает выучить JS, css, фремворк, научиться программировать, сделать пару-тройку проектов в составе команды n человек и становится тим-лидом. С тех пор, как С++ разработчики куда то подевались, миллионы приложений стали писаться на js. Свято место пусто не бывает.
5 Клауд — все думали, что замедление роста CPU даст тот самый Ренесанс С++, но вышло ровно наоборот — вычислительные мощности девальвировались в десятки и даже сотни раз. Типичый С++ник прежде всего считает байты и такты и готов любого порвать даже за лишний бит.
6 Типичный цикл разработки сократился в десятки раз. Вместо "раз в год" стало "раз в месяц". Проект на с++ еле-еле успевает скомпилироваться.
То есть, в целом экономика индустрии повернулась не в пользу плюсов. Поэтому буйно цветут именно managed технологии, из которых два явных лидера — Java и JavaScript.
WPF — скорее всего RIP, используется только в старючих корпоративных проектах 2008-2010 годов. Как бывший разработчик в том силе на WPF — могу подтвердить, то новые проекты на WPF ни кто не делает.
Просто на js фреймворке + bootstrap можно сделать UI, который ничем не будет уступать WPF. Так что большинство сейчас клепают веб-интранет приложения. А если еще адаптивная верстка, то можно и в браузере на мобилках.
А если еще ionic...
Если бы MS изначально сделала WPF кроссплатфоменным фрейворком, то у него были бы шансы на жизнь, а так нет. Сейчас больше пользователей не на винде.
T>"никто" пришется вместе: в школе на территории бу тебя русскому не научили, наверное
У нас не форум русского, пенять на грамматические ошибки и очепятки. Это путь к бану ;)
T>на скрипте написать то, что хочется бизнесу , конечно, можно, но времени надо в разы больше, поэтому и WPF чувствует себя очень даже хорошо
Вообще не напряжно писать UI на том же ангуляре 2+ и bootstrap и коробки. На WPF нужно больше усилий для того, что бы стили применить.
T>по поводу мобилок скажу только одно слово: "Xamarin"
А я тебе скажу, что Xamarin — убогая фигня, в которой у тебя два вью для любого для iOS & Android только модель вью общая — это да.
P.S. Я не знаю, может за 1.5 года, что я Xamarin видел, что-то улучшилось...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vdimas, Вы писали:
V>>Там события мыши/клавы обрабатываются в одном потоке, ресолвинг атррибутов композиции происходит в другом, ну а драйвер 3D шлёт сцену в картейку в третьем. V>>В браузере ведь "движок" отделён от остальных подсистем? C>Нет. В браузере нынче сцена рендерится параллельно. Т.е. расчёт стилей элементов, их границ и т.д. C>См.: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
Вот это всё реально "писями по воде виляно".
Для эффективной параллельной обработки "стилей элементов, их границ и т.д." этот самый browser должен реально захватить всю машину — все её cores. Иначе это сплошные context switches.
Т.е. больше ничего не делать полезного кроме как рисовать UI на том бедном PC. Это путь в никуда.
И с этим мы уже наелись. Вариант Node.js обработки в одном потоке против multi-threading обработки как тому подтверждение.
Mozilla со своими идеями вообще загнется в скорости. Не потому что её съедят, а потому что сначала делать язык чтобы на нем написать потом browser это путь через задницу, простите мой французский.
Да и проблема которую решает Rust (утечки памяти) она надуманна, я её не понимаю если честно. Во всяком случае то что можно в C++ сделать просто культурой кода не стоит тех титанических усилий.
То что MS взяла за основу WebKit, а не Servo как бэ намекает. Уж у MS опыта работы со всякими managed решениями хватат по самы помидоры.
_>WPF — скорее всего RIP, используется только в старючих корпоративных проектах 2008-2010 годов. Как бывший разработчик в том силе на WPF — могу подтвердить, то новые проекты на WPF ни кто не делает.
_>Просто на js фреймворке + bootstrap можно сделать UI, который ничем не будет уступать WPF. Так что большинство сейчас клепают веб-интранет приложения. А если еще адаптивная верстка, то можно и в браузере на мобилках. _>А если еще ionic...
"никто" пришется вместе: в школе на территории бу тебя русскому не научили, наверное
на скрипте написать то, что хочется бизнесу , конечно, можно, но времени надо в разы больше, поэтому и WPF чувствует себя очень даже хорошо
по поводу мобилок скажу только одно слово: "Xamarin"
Здравствуйте, Sharov, Вы писали:
S>Ну коммерческая разработка с wf без Telerik'а или C1 сложно представить, поэтому корп. политики тут не приграда.
Какие нафиг политики — я уже из трёх проектов выпилил нафиг этот кусок серой субстанции! Хуже компонентов я ещё не встречал, а их саппорт вообще состоит из клинических идиотов
Жесть конечно. Исключений в языке как-бы нет, но проблемы из-за необходимости их учитывать все на месте От предложенных костылей ощущение надругательство над семантикой владения из-за которой вся пляска и началась Но всё равно вклад в развитие ЯП считаю из-за раста будет — всё-таки методом проб и ошибок надо найти как сделать и чтоб без GC и чтоб удобно было.
Здравствуйте, takTak, Вы писали:
T>аргумент очень простой: пусть цветут все цветы, T>на WPF написана такая куча приложений, что переписывание их на скриптe будет длиться десятилетия и будет стоить триллионы, T>да и то не факт, что получится что-то близко сопоставимое
GitHub Windows Desktop Client был написан на WPF, после того (или во время) как MS купила GitHub этот клиент переписан на Electron.
Здравствуйте, EM, Вы писали:
EM>Поставим вопрос так — на чем писать UI внутри корпоративной трейдинговой системы.все клиенты на Винде. EM>Мой ответ Чемберлену — wpf.
Так действительно было, но сейчас уже нет. Про всех говорить не буду, но JPМ, MS, BoA, Pimco уходят с .NET в новых системах. Самое смешное, что WPF в одном из них таки пока используют, но исключительно через бридж из питона.
Здравствуйте, Cyberax, Вы писали:
T>>дураками их никак не могу назвать, так как этот их продукт до сих пор регулярно использую и для тех задач, для которых эта штука применяется, ничего лучше до сих пор нет C>JS+HTML
Я тут смотрю доклады с Chrome Dev Summit 2018:
Говорят будет нативный список с виртуализацией (может быть, когда-нибудь) — то что во всех вменяемых GUI фреймворках есть с рождения. Пока предлагают пользоваться джава скриптовыми реализациями
которых куча и надо самому выбрать нормально работающую и интегрировать в свой фреймворк:
аргумент очень простой: пусть цветут все цветы,
на WPF написана такая куча приложений, что переписывание их на скриптe будет длиться десятилетия и будет стоить триллионы,
да и то не факт, что получится что-то близко сопоставимое
для новых пёстрых говноформочек с четырьмя импутбоксами и одной кнопкой подойдёт и скрипт
Здравствуйте, Serginio1, Вы писали:
_>>Что там по кол-ву буковок? S> При этом в WPF ты ни строчкт не пишешь, а используешь визульный редактор.
Визуальный редактор — это огромный анти-паттерн. Он означает, что UI невозможно нормально положить в репозиторий и работать над ним нескольким людям.
И при этом он не сокращает время разработки, совсем.
Такое ощущение, что выложили кукую-то фигню пока. С гитхаба:
We are part-away through porting WPF to .NET Core, and will complete that for .NET Core 3.0. We intend to bring the codebase up to functionality and performance parity with .NET Framework.
We have published only a small part of the WPF source. We will continue to publish WPF components as part of the .NET Core 3 project.
В roadmap'e собираются неспеша в следующем году частями пилить и выкладывать.
Здравствуйте, novitk, Вы писали:
N>До того момента, когда стали популярны реактивные js-фреймворки, электроны и прочие QtQuick. В общем очередной легаси-фреймворк для легаси-языка, используемого в легаси-проектах. От опенсорсинга будет ни жарко ни холодно.
На самом деле рано кричите "гоп". Еще не ясно чья возьмет. Спешите. Вот уж WebAssembly и Blazor на подходе. Евангелисты пишут что JS-фреймворки — это поезд, который движется к пропасти. Возможно так и есть.
Оно всегда так — кажется стабильным и несокрушимым, а потом в один миг все рушится.
Здравствуйте, Shmj, Вы писали:
S>На самом деле рано кричите "гоп". Еще не ясно чья возьмет. Спешите. Вот уж WebAssembly и Blazor на подходе. Евангелисты пишут что JS-фреймворки — это поезд, который движется к пропасти. Возможно так и есть.
Без нормального DOM-байдинга, которое неизвестно когда будет, wasm всего лишь нишевое решение для апплета внутри страницы. WPF для таких задач не нужен. Если байндинг появится, опять же не нужен, так как у WPF совершенно другой DOM. Btw перенести WPF на wasm, даже если net core там уже работает, практически невозможная задача, так как нужных API(DirectX) там просто нет и никогда не будет.
Здравствуйте, Danchik, Вы писали:
D>Кагбы некоторые считают что это "гавно" намного лучше спроектировано и работает чем JS движки.
Ну, в том, что такие люди есть, я не сомневаюсь. Но оно разве где-то юзается, кроме набивших оскомину интерфейсов студии и автокада (или уже и оттуда выпилили)? Помню, вроде еще когда-то у каталиста интерфейс был на ВПФ, тормозило жутко.
Здравствуйте, Ikemefula, Вы писали:
I>Последние проекты для плюсов, о которых я слышал, представляли собой интеграцию c V8, написание плагинов к Cordova, Android, модулей к node и кое какие приседания с nginx и lua. I>Т.е. примерно так — часть ушла в node или unity, часть ушла в джаву, часть — в эмбеддед разработку на жесточайшем Си-без-плюсов.
I>Причин много на самом деле
N>Так действительно было, но сейчас уже нет. Про всех говорить не буду, но JPМ, MS, BoA, Pimco уходят с .NET в новых системах. Самое смешное, что WPF в одном из них таки пока используют, но исключительно через бридж из питона.
на что именно они уходят? и сколько из проектов реализуются в штатах, а не где-то между калькуттой и даккой?
скорее всего, "ифективные менаджеры" решили , что кормить пять-десять кумаров вместо одного джона всё равно прибыльнее, если исходить из логики выплат бонуса в ближайших двух кварталах, а потом можно и на другое место перейти
T>>на что именно они уходят? N>Большинство на Питон. Кое-кто на Скалу.
T>>и сколько из проектов реализуются в штатах, а не где-то между калькуттой и даккой? N>Проекты глобальные. ~80% кода идет из Нью-Йорка, Лондона, Токио, Сингапура и Гонконга.
имеется в виду, что яваскрипт рекомпилируется из скалы о аналогии с Fable( F# -> Javascript) ?
и с питоном что-то похожее есть(нативная поддержка фронтенда в самом питоне вроде совсем ужасная была...)?
функциональный стиль на стороне сервера — ещё понятно, а всё остальное .... не понимаю прикола...
T>>"никто" пришется вместе: в школе на территории бу тебя русскому не научили, наверное O>А в начале предложения ставится большая буква. Тебя, очевидно, тоже. T>>на скрипте написать то, что хочется бизнесу , конечно, можно, но времени надо в разы больше, поэтому и WPF чувствует себя очень даже хорошо O>Всё-таки первично здесь владение средствами у конкретного разработчика. T>>по поводу мобилок скажу только одно слово: "Xamarin" O>Вроде эта гадость без интернета не работает, и на неё могут в любой понедельник наложить санкции?
когда ты будешь знать три языка, как я, причём и такие, в которых каждое второе слово пишется с заглавной буквы, тогда и у тебя появится чувство целесобразности тех или иных конструкций, вот тогда и поговорим
для индустрии как таковой важны навыки не одного конкретного, а именно среднего разработчика, я приводил пример элементарной валидации, которая делается на WPF за пару часов, на скрипте без сторонних готовых библиотек речь пойдёт уже о неделях
Здравствуйте, IID, Вы писали:
ЭФ>>>Вы мне скажите — Qt RIP или нет? D>>Какой нафиг рип, ты оч ем? Развивается с первой космической скоростью. Вчера вышло обновление последнее. IID>Крайне мутная политика лицензирования. IID>Для небольших компаний просто неподъёмные условия. Типа $300/разработчик ежемесячно, или теряешь возможность даже продавать уже написанное и сделанное. В т.ч. устройства, в фирмвари которых использовалась QT. IID>Да, смотрят сквозь пальцы, но сама ситуация на корню рубит возможность продать потом устройства крупному бизнесу, под их имя. Вместо расхлёбывания мутного лицензирования те просто купят у конкурентов.
Это ты вообще о чём? Там же есть lgpl лицензия, которая практически свободная.
T>>ну, кстати, я помню интервью с кем-то из тех, кто WPF проектировал: он открыто признал, что помешанность на XML была ошибкой, хотя когда они библиотеку проектировали, наверное, никакого json и в помине не было _>Css тогда точно был. А вот мозгов не было. Поэтому если бы даже взяли json — испохабили бы также.
вообще-то это было время, когда все, включая ibm, sun, google и т.д. ваяли SOAP сервисы и ничего другого, кроме cobra, .remoting / RPC не былo
я лично считаю, что для выпущенной 12 лет назад бибиотеки (а разрабатывался и проектировался он ещё раньше) WPF как продукт просто превосходный;
дураками их никак не могу назвать, так как этот их продукт до сих пор регулярно использую и для тех задач, для которых эта штука применяется, ничего лучше до сих пор нет
Здравствуйте, white_znake, Вы писали:
_>Подозрение, что квалификация WPF разработчика — senior, а js + html + css — ниже?
Учитывая скорость появления и умирания говнофреймворков на js, как там вообще могут быть сеньоры? _>Просто когда используешь уверенно все фишки html5 + css3, то аналогичные вещи можно сделать написав меньше кода, чем на WPF.
Бред.
_>А какие причины для отстрела ноги в js + html + css?
Рукожопие в связи с новизной очередного говнофреймворка (который кстати школохипстеры объявят "немодным" и obsolete до того, как ты успеешь завершить проект), помноженное на феноменальную убогость тулчейна и самого языка.
Здравствуйте, takTak, Вы писали:
T>я лично считаю, что для выпущенной 12 лет назад бибиотеки (а разрабатывался и проектировался он ещё раньше) WPF как продукт просто превосходный;
Да. Для 12-ти лет назад. Но не сейчас.
T>дураками их никак не могу назвать, так как этот их продукт до сих пор регулярно использую и для тех задач, для которых эта штука применяется, ничего лучше до сих пор нет
JS+HTML
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Говорят будет нативный список с виртуализацией (может быть, когда-нибудь) — то что во всех вменяемых GUI фреймворках есть с рождения. Пока предлагают пользоваться джава скриптовыми реализациями ЕА>которых куча и надо самому выбрать нормально работающую и интегрировать в свой фреймворк:
И шо? Давно известно, что на JS надо всё самому делать (точнее, подключать нужную библиотеку). Типа: https://akryum.github.io/vue-virtual-scroller/#/dynamic
Что гораздо лучше поможет — это поддержка shadow DOM во всех браузерах. С ним уже можно делать полностью плавную анимацию без всяких задержек, даже при необходимости тяжёлых элементов управления.
ЕА>А еще говорят многопоточность будет (когда-нибудь, и если пишешь на веб-ассембли)
Это сильно обманчивая новость. Рендеринг HTML+CSS в браузерах уже давно многопоточный и аппаратно-ускоренный, такого в WPF не осилили до сих пор. Однопоточным является выполнение скриптов.
Здравствуйте, c-smile, Вы писали:
CS>Да помер он уже давно. MFC был еще как-то актуальным лет 20 назад. Когда он был фреймоворком MS Office (т.е. 25 лет назад). И когда рынок его компонентов приносил хоть какие-то деньги. CS>Теперь это удел маргиналов.
Или если требуется ембеддить OLE-документы друг в друга, то сегодня альтернативы MFC на эту часть проекта нет.
Здравствуйте, alex_public, Вы писали:
_>Это ты вообще о чём? Там же есть lgpl лицензия, которая практически свободная.
Она не работает, если вы поставляете hardware без возможности заменить используемый там Qt на свой собственный. Никто не будет заморачиваться и вставлять в кофеварку порты для апдейта версии кутэ. Не говоря уже о том, что если собирать всё в статике с использованием QtLite вам будет нереально вписаться в lgpl. Собственно Qt на этом и делает деньги. Многие автопроизводители сейчас используют Qt.
А для десктопа да — одно удовольствие, можно юзать бесплатно и продавать. Пока достойных аналогов для C++ нет и не предвидится.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Проекты глобальные. ~80% кода идет из Нью-Йорка, Лондона, Токио, Сингапура и Гонконга. НС>Ну да, пастухи-надсмотрщики там, да. А вот овцы больше во всяких бангалорах. И только особо преданных могу забрать в метрополию на H1B.
Я говорю именно о разрабах, а не о менеджменте. Бангалор и пастухи-мэнеджеры используется конечно для перефирии, но не для ключевых компонентов.
Здравствуйте, C0x, Вы писали:
C>>Ещё проблема в том, что если делать масштабируемые формы, то визуальный редактор уже начинает даже и мешать. Так как не видно структуры (что куда масштабируется). C0x>Позволь спросить, ты много с wpf работал?
Да, в районе 2011-го года. С тех пор что-то поменялось?
Здравствуйте, Cyberax, Вы писали:
C>>>Ещё проблема в том, что если делать масштабируемые формы, то визуальный редактор уже начинает даже и мешать. Так как не видно структуры (что куда масштабируется). C0x>>Позволь спросить, ты много с wpf работал? C>Да, в районе 2011-го года. С тех пор что-то поменялось?
Нет. Точно так же порядок по прежнему имеет в XAML значение, поэтому редактор просто так ничего не переупорядочивает.
Здравствуйте, C0x, Вы писали:
C0x>Ну я использую WinForms. Предложи мне что-то лучшее для следующей задачи: C0x>Требования: создать приложение с 4-5 формочек. Приложение массовое, инсталлируемое. C0x>Хочу делать быстро и по большей части рисовать интерфейс визуально мышкой, а не ковыряться в коде и скриптах. C0x>Хочу использовать нормальную среду разработки, которая называется Visual Studio. Всякие vim, eclipse и прочее Гик-говно не предлагать.
Ну например на Qt это будет и быстрее в разработке и кроссплатформеннее (причём я имею в виду не ненужный Линух, а мобилки).
I>>>Сейчас на десктопе основной конкурент это JS, именно на него переписывают многие приложения.
T>>ни одного такого приложения сам своими глазами не видел
I>Скайп. SQL Management Studio.
T>>недавно, кстати, узнал что изначально написанный на яваскипте Azure Storage Explorerбыл переписан на C# (Blazor + Electron.NET) T>>яваскрипт, "давай, досвиданья"
I>
I>This was just an experiment
скайп, как я тут уже написал раннее, стал, скорее антирекламой электрона, и тут только с этого форума несколько человек со мной согласны
про SQL Management Studio — интересно, какая имеется в виду? вот посмотрел на ту версию, что у меня на компе: SQL Server 2016 13.0.16106.4, она вроде никак ни с каким яваскриптом не связана, или ?
вот именно ! эксперимент, скорее всего, длился пару часов, если найдутся кумары, которых нечем занять, то перепишут что угодно
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>> При этом в WPF ты ни строчкт не пишешь, а используешь визульный редактор.
_>Необходимость использовать визуальный редактор для простейших стилей — это есть скорее всего попытка скрыть лажу в оверхеде. Я могу css и html накидать хоть в блокноте. _>И это мощный плюс...
Плюсы тоже не используют интеллисенис и пишут в блокноте. Признать это премуществом даже сишники не могут и переходя на C# называют его детским языком. Он так прост.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Cyberax, Вы писали:
C>Ещё проблема в том, что если делать масштабируемые формы, то визуальный редактор уже начинает даже и мешать. Так как не видно структуры (что куда масштабируется).
Это каким это образом структура формы может быть видна в коде и при этом будет не винда в визуальном редакторе? )))
CS>Да и проблема которую решает Rust (утечки памяти) она надуманна, я её не понимаю если честно. Во всяком случае то что можно в C++ сделать просто культурой кода не стоит тех титанических усилий.
Гикам и всяким фанатикам "написать браузер на C++ по стандартам кодирования" ты просто не продашь. Аккуратно писать на C++ это обычно не весело нифига, и нет никакой особой репутации или чувства приобщения к элите. Если на C++ развивать старый движок, с тоннами легаси, в то время как рядом с ураганной скоростью развивается хром — так и вообще, год работы даст меньше пафоса чем один принятый коммит в хром. А вот сначала выпилить вундервафлю, а потом на этой вундервафле выпилить браузер — это прикольно, с этим можно и на конференции выступить, людей жизни научить.
Хотя вундервафля по своему устройству, имхо, долгое время подходила для написания браузеров хуже наверное всех языков на свете. Чего стоят только проблемы с такой базовой структуркой данных как дерево. Это в 2018-м году, через 3 года после релиза. Ёлки-палки, да браузер это сплошная работа с вложенными структурами которые перекрёстно ссылаются друг на друга.
T>>Microsoft SQL Operations Studio !? WTF ! я даже не знаю, о чём ты говоришь... то что подавляющее большинство используeт- SQL Management Studio
НС>SSMS только под венду, так что на всяких линуксах альтернативы operations studio нет.
и да, этот новый " sql иксплорер" под линух — это 10-15% функциональности от того , с которым работает курящий здоровый разработчик человек
Здравствуйте, white_znake, Вы писали:
_>Ты просто не можешь аргументировано спорить. То, что html, css, js развиваются (ну да, старые фреймворки умирают, новые появляются) — это наоборот хорошо. А то, что WPF так и застыл на уровне 2000-х — это ни есть плюс, а скорее минус.
Это хорошо только для короткоживущих говнопроектов хомячков. Ибо реальные приложения надо поддерживать годами, а то и десятилетиями. И "поддерживать" не значит постоянно переписывать на очередной говнофреймворк, которые хомячки объявили "крутым" в определённый момент времени.
_>Не бред, просто посмотри стиль для кнопки на html5 + css3 и аналогичный стиль в XAML. В XAML букв будет больше
Мдя. Ты точно знаешь WPF?
_>Ни кто не заставляет тебя делать продукт на самой первой версии фреймворка. _>Я сам не стал изучать Angular1, потому что решил подождать, когда выйдет вторая версия, и не прогадал.
Ты какая там нынче версия актуальна?
_>P.S. А в WPF пофиксили необходимость костылей для натягивания MVVM на popups? Или до сих пор "магия" нужна?
Если руки растут из правильного места, то ничего никуда натягивать не нужно.
Здравствуйте, SaZ, Вы писали:
SaZ>Так Qt уже умеет WebAssembly. Да и вообще они далеко замахнулись, но боюсь что будет как с QBS — не пропихнут из-за плохого маркетинга.
Там дело не в маркетенге, до него не дошло, qbs никогда официально не пиарили за пределами блогов. Это внутренняя политика. Я прочитал все доступную переписку по этому вопросу и у меня сложилось впечатление что это решение продавил мэйнтейнер QtCore Thiago Macieira. Он преднамеренно выдвинул не выполнимые для qbs требования: типа быть доступной из коробки в нескольких линуховых дистрибутивах 3 года или что-то такое, он открыто заявлял, что система сборки должны быть "стандартной" (autotools и cmake), даже если она плоха.
Может еще KDABчто-то пообещали, они любят cmake.
В общем в цифром аду есть особое место для Ларша Кнола и Тиаго Масейра
SaZ>Впрочем, у того же Qt есть огромная ниша, куда .net+WPF не влезут — это embedded разработка.
Причем ниша растет семимильными шагами из-за роботизации
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И все как один — уродские.
ТЫ наверное про WYSIWYG редакторы? НУ да, они не очень.
Мне хватает html редактора в chrome :)
_>>Чем тебе не нравятся существующие? НС>Тем что они генерят кривой html. Нормальный html написать — даже для человека серьезная задача, требующая большого и специфического опыта, и правильного мышления. WPF в этом плане сильно дружелюбнее.
Ну да, проблема с WYSIWYG редакторами — большая.
Но сейчас тебе не надо писать с нуля все стили для страницы. Подключаешь bootstrap, указываешь стили bootstrap и вуаля — готово.
Похоже с html у тебя не очень. Я сам был таким, потратил недельку упорного труда и теперь не смотрю на html с подозрением.
Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная. Подключение стилей в css, тоже более понятно, ни каких статический / динамических словарей.
Здравствуйте, Danchik, Вы писали:
ЭФ>>>Давайте же обсудим!
ARK>>Это говно кто-то использует?
D>Кагбы некоторые считают что это "гавно" намного лучше спроектировано и работает чем JS движки.
И кто эти некоторые ? Надеюсь, не местные мыслители ?
Можно взглянуть на аргументы этих избранных ?
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, в том, что такие люди есть, я не сомневаюсь. Но оно разве где-то юзается, кроме набивших оскомину интерфейсов студии и автокада (или уже и оттуда выпилили)? Помню, вроде еще когда-то у каталиста интерфейс был на ВПФ, тормозило жутко.
Используется.
Популярность не говорит о качестве технологии.
А большая часть тормозов wpf уже давно излечена.
Здравствуйте, c-smile, Вы писали:
CS>GitHub Windows Desktop Client был написан на WPF, после того (или во время) как MS купила GitHub этот клиент переписан на Electron.
Ну так WPF не кроссплатформенный, и не факт что им станет даже после переписывания на кору.
так вроде говорят, что WPF только для винды, для всего остального обещают когда-то в 20-ых годах, если майкрософт доживёт и не передумает, хотя есть сомнения, что индусы на что-то такое низкоуровневое окажутся способны
Здравствуйте, EM, Вы писали:
_>>WPF — скорее всего RIP, используется только в старючих корпоративных проектах 2008-2010 годов. Как бывший разработчик в том силе на WPF — могу подтвердить, то новые проекты на WPF ни кто не делает.
EM>Вот прямо сейчас начинаю новый проект. EM>В финансах wpf везде. А это основной потребитель ИТ услуг
Это не так.
_>>Просто на js фреймворке + bootstrap можно сделать UI, который ничем не будет уступать WPF.
EM>Мне нравится ваш энтузиазм. EM>Возьмётесь на нем сделать GUI трейдинговой системы ? С соответствующими требованиями к надёжности и быстродействию
Я не знаю, что мешает сделать надежный и быстрый UI на js + html? Может кривые руки? Обычно не язык и фреймворк определяет качество продукта ;)
Ты лучше расскажи, как это приложение портировать на планшетники будете?
Здравствуйте, white_znake, Вы писали:
EM>>Мне нравится ваш энтузиазм. EM>>Возьмётесь на нем сделать GUI трейдинговой системы ? С соответствующими требованиями к надёжности и быстродействию
_>Я не знаю, что мешает сделать надежный и быстрый UI на js + html?
Попробуй сделать что то реально сложное и сразу узнаешь.
Даже на наиболее прогрессивной связке angular2/typescript + flux
_>Ты лучше расскажи, как это приложение портировать на планшетники будете?
Любитель из головы выдумывать требования к продукту?
Поставим вопрос так — на чем писать UI внутри корпоративной трейдинговой системы.все клиенты на Винде.
Мой ответ Чемберлену — wpf.
Твой, я так понимаю — вот это — https://wtfjs.com/
Ок. Я пойду другим путем
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, EM, Вы писали:
EM>Поставим вопрос так — на чем писать UI внутри корпоративной трейдинговой системы.все клиенты на Винде. EM>Мой ответ Чемберлену — wpf.
Здравствуйте, takTak, Вы писали:
N>>Без нормального DOM-байдинга, которое неизвестно когда будет T>было бы ещё правильнее выкинуть сам DOM на помойку
Rендерить в канвас ты можешь и сейчас. Tы предлагаешь другой markup?
S>>>А почему не winforms, кстати? Чем оне хуже?
T>>1) структурировать код сложнее
S>В смысле, сложнее чем что?
T>>2) проблемы с привязкой данных
S>Возможно, у wpf с ентим вроде получше.
T>>3) нет возможности скалировать приложение автоматически
S>Это как? Что значит "скалировать"?
T>>4) нет поддержки тем и стилей
S>Неправда. Есть Telerik, C1 которые все енто умеют.
MVVM на WinForms сложно реализовать, т.е. при WinForms надо иметь кого-то , кто будет бить по рукам каждый раз, когда разработчик попытается что-то прилепить в "CodeBehind", а это сложно проверить
сорри, "скалировать"ся — это типа автоматически менять размер в зависимости от разрешения экрана/размера окна приложения
это всё , конечно, хорошо, что кто-то чего-то умеет, но иногда из-за корпоративной политики чего-то разрешается или не разрешается и тогда неплохо, если подправить можно тем, что есть в самой первой коробке
Здравствуйте, takTak, Вы писали:
T>MVVM на WinForms сложно реализовать, т.е. при WinForms надо иметь кого-то , кто будет бить по рукам каждый раз, когда разработчик попытается что-то прилепить в "CodeBehind", а это сложно проверить
T>сорри, "скалировать"ся — это типа автоматически менять размер в зависимости от разрешения экрана/размера окна приложения
Благодарю, это я тупанул.
T>это всё , конечно, хорошо, что кто-то чего-то умеет, но иногда из-за корпоративной политики чего-то разрешается или не разрешается и тогда неплохо, если подправить можно тем, что есть в самой первой коробке
Ну коммерческая разработка с wf без Telerik'а или C1 сложно представить, поэтому корп. политики тут не приграда.
N>>>Без нормального DOM-байдинга, которое неизвестно когда будет T>>было бы ещё правильнее выкинуть сам DOM на помойку N>Rендерить в канвас ты можешь и сейчас. Tы предлагаешь другой markup?
да, иметь что-то попроще и погибче было бы неплохо, типа markup for in-memory-key-value collection etc.
я ничего не предлагаю, но ведь главная проблема интернета — это то, что он работает с разметкой, а не напрямую с памятью/стримом, все эти реакты не возникли бы, если бы была более продвинутая модель рендеринга, чем html
Здравствуйте, takTak, Вы писали:
T>я ничего не предлагаю, но ведь главная проблема интернета — это то, что он работает с разметкой, а не напрямую с памятью/стримом, все эти реакты не возникли бы, если бы была более продвинутая модель рендеринга, чем html
У реакта разница в механизме обновлений, а не в самой модели разметки/DOM-a. Вероятно полезно реализовать подобный механизм в нативном API браузера, но мир это не изменит.
Здравствуйте, EM, Вы писали:
EM>Здравствуйте, white_znake, Вы писали:
EM>>>Мне нравится ваш энтузиазм. EM>>>Возьмётесь на нем сделать GUI трейдинговой системы ? С соответствующими требованиями к надёжности и быстродействию
_>>Я не знаю, что мешает сделать надежный и быстрый UI на js + html?
EM>Попробуй сделать что то реально сложное и сразу узнаешь. EM>Даже на наиболее прогрессивной связке angular2/typescript + flux
Angular 6 уже давное зарелизен. Релиз Angular 7 на подходе. Ты уверен, что Angular2 до сих пор прогрессивен?
А какие проблемы у тебя возникли? Просто работал в прошлой компании и разрабатывали трейдинг, писали клиента на js. Взаимодействие с сервером через веб сокеты. Сам сервер Node.JS часть на Go.
_>>Ты лучше расскажи, как это приложение портировать на планшетники будете? EM>Любитель из головы выдумывать требования к продукту?
Просто подумал вдруг трейдинг? Сейчас типа модно зафигачить свою платформу, торговые алгоритмы и продавать услуги по трейдингу хомякам и мелким компаниям.
Так вот хомяки не будут рады винде :)
EM>Поставим вопрос так — на чем писать UI внутри корпоративной трейдинговой системы.все клиенты на Винде. EM>Мой ответ Чемберлену — wpf.
Да это твое дело :)
EM>Твой, я так понимаю — вот это — https://wtfjs.com/ EM>Ок. Я пойду другим путем
Я так и думал, что кроме C#, ты ни чего особо не знаешь :) Кстати в .NET Framework своих граблей хватает и в плане работы с сетью и в плане работы с многопоточностью.
EM>>Поставим вопрос так — на чем писать UI внутри корпоративной трейдинговой системы.все клиенты на Винде. EM>>Мой ответ Чемберлену — wpf.
N>Так действительно было, но сейчас уже нет. Про всех говорить не буду, но JPМ, MS, BoA, Pimco уходят с .NET в новых системах. Самое смешное, что WPF в одном из них таки пока используют, но исключительно через бридж из питона.
Здравствуйте, Ikemefula, Вы писали:
I>>>Так пахнет, что позаканчивались недесктопные проекты? НС>>Где они позаканчивались? I>Много где и такая картина в разных странах.
Здравствуйте, takTak, Вы писали:
T>на что именно они уходят?
Большинство на Питон. Кое-кто на Скалу.
T>и сколько из проектов реализуются в штатах, а не где-то между калькуттой и даккой?
Проекты глобальные. ~80% кода идет из Нью-Йорка, Лондона, Токио, Сингапура и Гонконга.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Вы мне скажите — Qt RIP или нет?
Какой нафиг рип, ты оч ем? Развивается с первой космической скоростью. Вчера вышло обновление последнее. Причем там уже давно не только десктопы, но и эмбеддед системы со своим стеком. Они давно вышли из области обычной GUI библиотеки.
Здравствуйте, takTak, Вы писали:
T>имеется в виду, что яваскрипт рекомпилируется из скалы о аналогии с Fable( F# -> Javascript) ? T>и с питоном что-то похожее есть(нативная поддержка фронтенда в самом питоне вроде совсем ужасная была...)?
Scala.js не используется. Архитектура похожа на dash фрэймворк в питоне. Пользователи из веб зоопарка имеют доступ только к css, js/html/angular под контролем фреймворка.
T>"никто" пришется вместе: в школе на территории бу тебя русскому не научили, наверное
А в начале предложения ставится большая буква. Тебя, очевидно, тоже. T>на скрипте написать то, что хочется бизнесу , конечно, можно, но времени надо в разы больше, поэтому и WPF чувствует себя очень даже хорошо
Всё-таки первично здесь владение средствами у конкретного разработчика. T>по поводу мобилок скажу только одно слово: "Xamarin"
Вроде эта гадость без интернета не работает, и на неё могут в любой понедельник наложить санкции?
Здравствуйте, white_znake, Вы писали:
_>Просто на js фреймворке + bootstrap можно сделать UI, который ничем не будет уступать WPF. Так что большинство сейчас клепают веб-интранет приложения. А если еще адаптивная верстка, то можно и в браузере на мобилках.
На прошлом проекте у нас тоже дали дань моде. Именно как ты хотел.
В итоге, форму, которую WPF разработчик сделает за день — они втроем пилили неделю. И так везде на фронте.
js + css для тяжеловесных винприложений не от ума.
_>А если еще ionic...
Не говоря уже о поддерживаемости решения на WPF. Отстрелить себе ногу на нем в разы сложнее.
Здравствуйте, white_znake, Вы писали:
_>Вообще не напряжно писать UI на том же ангуляре 2+ и bootstrap и коробки. На WPF нужно больше усилий для того, что бы стили применить.
Прописать в ресурсдикшионари ссылку или поставить прямую ссылку на стиль — это больше? Не, я понимаю, что 10 лет прошло, но нельзя так забывать.
_>А я тебе скажу, что Xamarin — убогая фигня, в которой у тебя два вью для любого для iOS & Android только модель вью общая — это да.
Первый раз слышу, что вью не должно быть специализированным. Странное у тебя понимание MVVM.
Здравствуйте, white_znake, Вы писали:
_>Если бы MS изначально сделала WPF кроссплатфоменным фрейворком, то у него были бы шансы на жизнь
Дело в мобилках и HTML5. Все эти технологии десктопные стоят гемора, но не дают никаких осязаемых преимуществ перед JS+CSS.
IT>>Прописать в ресурсдикшионари ссылку или поставить прямую ссылку на стиль — это больше? Не, я понимаю, что 10 лет прошло, но нельзя так забывать.
_>в index.html стиль указать еще проще
опять неверно у тебя в слове 10 токенов, а в моём всего 9: "app.xaml"
Здравствуйте, Denwer, Вы писали:
D>Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>Вы мне скажите — Qt RIP или нет?
D>Какой нафиг рип, ты оч ем? Развивается с первой космической скоростью. Вчера вышло обновление последнее.
Крайне мутная политика лицензирования.
Для небольших компаний просто неподъёмные условия. Типа $300/разработчик ежемесячно, или теряешь возможность даже продавать уже написанное и сделанное. В т.ч. устройства, в фирмвари которых использовалась QT.
Да, смотрят сквозь пальцы, но сама ситуация на корню рубит возможность продать потом устройства крупному бизнесу, под их имя. Вместо расхлёбывания мутного лицензирования те просто купят у конкурентов.
Крайне тормозной маркетинг. Ответили мне на письмо через 2 недели, причём ничего по-существу ни на один из конкретных заданных вопросов, а отписка "перезвоните нам и мы с удовольствием побеседуем".
К тому времени мы уже решили отказаться от планов перехода на QT.
D>Причем там уже давно не только десктопы, но и эмбеддед системы со своим стеком. Они давно вышли из области обычной GUI библиотеки.
Разве с 5ой версии не началось слияние эмбеддед обратно ? Я не "настоящий сварщик", так, слышал краем уха.
Здравствуйте, Denwer, Вы писали:
ЭФ>>Вы мне скажите — Qt RIP или нет? D>Какой нафиг рип, ты оч ем? Развивается с первой космической скоростью. Вчера вышло обновление последнее. Причем там уже давно не только десктопы, но и эмбеддед системы со своим стеком. Они давно вышли из области обычной GUI библиотеки.
Там уже давно не только десктоп и эмбеддед, но и мобильные системы. А в последних версиях появилась официальная поддержка WebAssembly. Т.е. Qt и раньше умудрялись компилировать под браузер с помощью emscripten, но это было скорее развлечением фанатов и не особо подходило для промышленного применения. А теперь прямо в самой Qt это будет полноценной платформой.
IT>>>Прописать в ресурсдикшионари ссылку или поставить прямую ссылку на стиль — это больше? Не, я понимаю, что 10 лет прошло, но нельзя так забывать.
_>>в index.html стиль указать еще проще ;)
T>опять неверно :facepalm: у тебя в слове 10 токенов, а в моём всего 9: "app.xaml"
IT>На прошлом проекте у нас тоже дали дань моде. Именно как ты хотел. IT>В итоге, форму, которую WPF разработчик сделает за день — они втроем пилили неделю. И так везде на фронте.
Подозрение, что квалификация WPF разработчика — senior, а js + html + css — ниже?
Просто когда используешь уверенно все фишки html5 + css3, то аналогичные вещи можно сделать написав меньше кода, чем на WPF.
IT>js + css для тяжеловесных винприложений не от ума.
ХЗ, не знаю, что ты имеешь в виду под тяжеловесным приложением... Клиент для трейдинга, клиент для инженерных расчетов (сопромат, расчет вентиляции) — это все легковесные клиенты или нет?
IT>Не говоря уже о поддерживаемости решения на WPF. Отстрелить себе ногу на нем в разы сложнее.
А какие причины для отстрела ноги в js + html + css?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Shmj, Вы писали:
S>>На самом деле рано кричите "гоп". Еще не ясно чья возьмет. Спешите. Вот уж WebAssembly и Blazor на подходе. Евангелисты пишут что JS-фреймворки — это поезд, который движется к пропасти. Возможно так и есть.
I>JS фремворк меняется за предсказуемое время. Это не проблема. Фремворки дохнут. Но точно так же передохли сотни UI библиотек для доса, виндовса и линукса. В живых осталось не так уж и много. I>Последние проекты для плюсов, о которых я слышал, представляли собой интеграцию c V8, написание плагинов к Cordova, Android, модулей к node и кое какие приседания с nginx и lua.
I>Т.е. примерно так — часть ушла в node или unity, часть ушла в джаву, часть — в эмбеддед разработку на жесточайшем Си-без-плюсов.
I>Причин много на самом деле I>2 Если раньше большинство проектов это были довольно сложные и тяжелы приложения, то сейчас вместо этого миллионы прикладных вещей, которые довольно легко можно запилить в браузере.
Можно, но какой дебил будет пилить приложение в браузере, если оно не требует онлайн доступа к данным и вообще онлайна?
I>3 В данный момент JS это единственное внятно работающее кроссплатформенное решение. "qt,qt,qt" @ из подвала
JS это кромешный ужас и тьма. Мир давно уже пытается от него избавиться.
I>4 С++ слишком сложен. Пока вырастет начинающий с++ разработчик, бухгалтер без образования успевает выучить JS, css, фремворк, научиться программировать, сделать пару-тройку проектов в составе команды n человек и становится тим-лидом. С тех пор, как С++ разработчики куда то подевались, миллионы приложений стали писаться на js. Свято место пусто не бывает.
С тех пор беда стала только больше. Появилась масса Говноприложений, которые не работают или работают так что с ними работать не хочется. Потом тратятся колосальные деньги чтобы это Говно все переписать правильно.
I>5 Клауд — все думали, что замедление роста CPU даст тот самый Ренесанс С++, но вышло ровно наоборот — вычислительные мощности девальвировались в десятки и даже сотни раз. Типичый С++ник прежде всего считает байты и такты и готов любого порвать даже за лишний бит.
Не надо делать из разработчиков Си++ дебилов. Просто 90% задач Си++ разработчиков находятся в тех областях, где экономия каждого байта действительно необходима.
I>6 Типичный цикл разработки сократился в десятки раз. Вместо "раз в год" стало "раз в месяц". Проект на с++ еле-еле успевает скомпилироваться.
Типичный цикл разработки Говноприложения — Хакатон на пару дней, публикация, смерть.
Сравни с типичным циклом нормального приложения: Прототип, проектирование, разработка с покрытием юниттестами, внутреннее тестирование, филдтестирование, публикация, сбор фидбэка, планирование, багфикс, разработка новых фич, покрытие юниттестами.......
I>То есть, в целом экономика индустрии повернулась не в пользу плюсов.
Экономика никуда не поворачивалась. Экномика растет и расширяется. Гдето достаточно Говноприложения на JS, Html лобать за пару дней, а где-то очень часто и на Ассемблере писать приходится.
I>Поэтому буйно цветут именно managed технологии, из которых два явных лидера — Java и JavaScript.
Ну я использую WinForms. Предложи мне что-то лучшее для следующей задачи:
Требования: создать приложение с 4-5 формочек. Приложение массовое, инсталлируемое.
Хочу делать быстро и по большей части рисовать интерфейс визуально мышкой, а не ковыряться в коде и скриптах.
Хочу использовать нормальную среду разработки, которая называется Visual Studio. Всякие vim, eclipse и прочее Гик-говно не предлагать.
ну, кстати, я помню интервью с кем-то из тех, кто WPF проектировал: он открыто признал, что помешанность на XML была ошибкой, хотя когда они библиотеку проектировали, наверное, никакого json и в помине не было
в WPF полно и других штук типа Multiple/Ancestor/ Parent / Style Trigger Inheritance: там , конечно, столько всего наворочено, что вряд ли найдётся кто-то, кто все эти взаимосвязи может быстро отследить
Здравствуйте, C0x, Вы писали:
C0x>Ну я использую WinForms. Предложи мне что-то лучшее для следующей задачи: C0x>Требования: создать приложение с 4-5 формочек. Приложение массовое, инсталлируемое. C0x>Хочу делать быстро и по большей части рисовать интерфейс визуально мышкой, а не ковыряться в коде и скриптах. C0x>Хочу использовать нормальную среду разработки, которая называется Visual Studio. Всякие vim, eclipse и прочее Гик-говно не предлагать.
Здравствуйте, alex_public, Вы писали:
_>Это ты вообще о чём? Там же есть lgpl лицензия, которая практически свободная.
1) Конечно же не свободная
2) Очень много компонентов в неё не входят
3) смешивать коммерческую и открытую лицензию запрещено
Собс-но нет (не было) проблемы купить коммерческую лицензию, НО!
— запрет поставлять своё ПО, если лицензия закончилась. Даже если разработка уже давно не ведётся. Просто продаём готовое со склада.
— самое мерзкое: необходимость покупать "рантаймы". Минимум 5000 штук!
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, c-smile, Вы писали:
CS>>GitHub Windows Desktop Client был написан на WPF, после того (или во время) как MS купила GitHub этот клиент переписан на Electron.
НС>Ну так WPF не кроссплатформенный, и не факт что им станет даже после переписывания на кору.
T>ну, кстати, я помню интервью с кем-то из тех, кто WPF проектировал: он открыто признал, что помешанность на XML была ошибкой, хотя когда они библиотеку проектировали, наверное, никакого json и в помине не было
Css тогда точно был. А вот мозгов не было. Поэтому если бы даже взяли json — испохабили бы также.
Здравствуйте, white_znake, Вы писали:
_>Хочешь помериться краткостью декларации стиля?
_>[xaml] _><Button> _> <Button.Style> _> <Style>
_>Что там по кол-ву буковок?
При этом в WPF ты ни строчкт не пишешь, а используешь визульный редактор.
EM>Поставим вопрос так — на чем писать UI внутри корпоративной трейдинговой системы.все клиенты на Винде. EM>Мой ответ Чемберлену — wpf.
По жизни тоже больше люблю десктоп и wpf, но с сожалением вынужден признать что для твоей задачи куда проще вообще не загоняться и взять готовое двигло от TradingView. Думаю для большинства сценариев ТА его хватит, более того многим трейдерам эта штука уже привычна и куча инструментов "искаропки" на своих местах. Внезапно, оно как раз на html+js.
Здравствуйте, C0x, Вы писали:
I>>Причин много на самом деле I>>2 Если раньше большинство проектов это были довольно сложные и тяжелы приложения, то сейчас вместо этого миллионы прикладных вещей, которые довольно легко можно запилить в браузере.
C0x>Можно, но какой дебил будет пилить приложение в браузере, если оно не требует онлайн доступа к данным и вообще онлайна?
Затем, что это проще всего. Онлайн тебе нужен, что бы запустить прилагу. Целая куча пва тупо обновляет само приложение, никак не используя данные на сервере.
I>>3 В данный момент JS это единственное внятно работающее кроссплатформенное решение. "qt,qt,qt" @ из подвала
C0x>JS это кромешный ужас и тьма. Мир давно уже пытается от него избавиться.
Пока что тренд такой, что на жээс переводят даже древние продукты и пихают вообще везде.
C0x>С тех пор беда стала только больше. Появилась масса Говноприложений, которые не работают или работают так что с ними работать не хочется. Потом тратятся колосальные деньги чтобы это Говно все переписать правильно.
Это нормально. Новый виток эволюции. В свое время было полно десктопных и консольных прилаг, которыми точно так же невозможно было пользоваться. Из того говна выросли все современные приложухи.
I>>6 Типичный цикл разработки сократился в десятки раз. Вместо "раз в год" стало "раз в месяц". Проект на с++ еле-еле успевает скомпилироваться.
C0x>Типичный цикл разработки Говноприложения — Хакатон на пару дней, публикация, смерть.
Такие вещи позволяют проверить ценность идеи, принять решение, инвестировать в нее или нет.
C0x>Сравни с типичным циклом нормального приложения: Прототип, проектирование, разработка с покрытием юниттестами, внутреннее тестирование, филдтестирование, публикация, сбор фидбэка, планирование, багфикс, разработка новых фич, покрытие юниттестами.......
Эта модель устарела. Сейчас более актуально быстро проверять идеи и внедрять только те, что дают профит или имеют такую перспективу.
Инвестировать год и узнать, что никому это не нужно — чистый убыток.
I>>Поэтому буйно цветут именно managed технологии, из которых два явных лидера — Java и JavaScript.
C0x>C# забыл.
T>вообще-то это было время, когда все, включая ibm, sun, google и т.д. ваяли SOAP сервисы и ничего другого, кроме cobra, .remoting / RPC не былo
cobra и soap в 2006-м уже уходили в прошлое. Их пик славы был почти одновременно с .NET 1.
К моменту выхода WPF, обоснованная критика XML-я уже звучала отовсюду где его успели использовать. Могли бы хотя-бы сменяемые "source providers" прикрутить, ведь прочитать/сохранить тэги и аттрибуты куда проще чем код. Тот же Winforms 1 умел и читать код, и писать, и сменные провайдеры у него были. Но не тут то было, в WPF всё прибили гвоздями.
Так что те кто херачил код — молодцы. А вот те кто утвердил XAML на десятилетия — облажались.
Здравствуйте, hi_octane, Вы писали:
_>Так что те кто херачил код — молодцы. А вот те кто утвердил XAML на десятилетия — облажались.
Ну а что вместо Xaml? Одно время конфиг файлы для .Net Core были на Json. Сразу было огромная куча критики на это примитивный формат.
Обратно вернули на Xml.
Есть визуальные редакторы. Можно смешивать как декларативное описание, так и программное создание элементов.
Ну и биндинг. Тому же ангулару ой как далеко до Wpf
и солнце б утром не вставало, когда бы не было меня
T>>вообще-то это было время, когда все, включая ibm, sun, google и т.д. ваяли SOAP сервисы и ничего другого, кроме cobra, .remoting / RPC не былo _>cobra и soap в 2006-м уже уходили в прошлое. Их пик славы был почти одновременно с .NET 1.
_>К моменту выхода WPF, обоснованная критика XML-я уже звучала отовсюду где его успели использовать. Могли бы хотя-бы сменяемые "source providers" прикрутить, ведь прочитать/сохранить тэги и аттрибуты куда проще чем код. Тот же Winforms 1 умел и читать код, и писать, и сменные провайдеры у него были. Но не тут то было, в WPF всё прибили гвоздями.
_>Так что те кто херачил код — молодцы. А вот те кто утвердил XAML на десятилетия — облажались.
SOAP как стандарт был закреплён в 2000, .NET 1.1 вышел в 2003; наверное, в это же время уже началось проектирование WPF, менеджерам , по-твоему, надо было ориентироваться не на существовавший W3C стандарт, а на твои хотелки из 2018 года? не слишком ли жирно будет?
или ты сможешь найти твои вопли негодования по данному поводу(XAML\XML) в интернете от 2003 года? сейчас их можно найти, если таковые , на самом деле, были
Здравствуйте, C0x, Вы писали:
C0x>Ну я использую WinForms. Предложи мне что-то лучшее для следующей задачи: C0x>Требования: создать приложение с 4-5 формочек. Приложение массовое, инсталлируемое. C0x>Хочу делать быстро и по большей части рисовать интерфейс визуально мышкой, а не ковыряться в коде и скриптах. C0x>Хочу использовать нормальную среду разработки, которая называется Visual Studio. Всякие vim, eclipse и прочее Гик-говно не предлагать.
CS>С помощью CSS ты можешь её застилировать под все что угодно, UWP, Material или что там у тебя.
Не буду называть это каким-то костылем для манагеров, чтобы никого не обидеть ненароком, но не понимаю как оно мне поможет написать приложение типа Доунлоадер файлов из сети?
Или приложение типа тотал коммандера? По-моему мы разном уровне приложений говорим.
Я бы ещё понял если бы ты про sciter сказал, который я серьезно рассматривал. Но скайтер, к сожалению обладая неимоверной мощью, так же страдает по сравнению с winforms своей избыточной сложностью. Я не сторонник рисовать интерфейс в коде. Я считаю что интерфейс нужно не программировать а рисовать визуально.
через пару лет тебе нужно будет твой UI переделать на более современные стили.
Причем глобально, т.е. все <input type=text> у тебя должны будут иметь "белый верх, красный низ".
Что ты будешь делать со своим "визуальным дизайнером" которого уже в природе может и не быть к тому времени ?
Здравствуйте, novitk, Вы писали:
N>До того момента, когда стали популярны реактивные js-фреймворки, электроны и прочие QtQuick.
Да пофик. ))
WPF — это, в сухом остатке, один из мощнейших способов разметки GUI + программное управление такой разметкой.
Причём, как сама разметка, так и код контролов не связаны с подробностями реализации "движка".
Движок можно заменить на более эффективный.
N>В общем очередной легаси-фреймворк для легаси-языка, используемого в легаси-проектах. От опенсорсинга будет ни жарко ни холодно.
Бгг...
То же самое можно было сказать об HTML.
Однако, именно open source сделал "легаси" WebKit вменяемого кач-ва, что теперь его наследник признан за "передовой". ))
У WPF сегодня те же проблемы, что было когда-то у HTML — стандарты застыли в развитии, при том что одновременно существовали несколько плохосовместимых реализаций стандартов.
Так и в экосистеме WPF сегодня — это сама WPF, плюс сервелат, плюс UWP, плюс Xamarin.
Вроде бы одно и то же, а в мелочах отличаются.
ИМХО, определённые усилия будут потрачены на выработку единого стандарта и принципов его будущего развития.
Затем развитие пойдёт уже со вменяемой скоростью.
Это все перделкисвистелки, которые нужны 3% приложений , а бизнес приложениям нужны стандартные удобные дизайны и контролы. Через 12 лет покупается библиотека с новыми контролами и одним движением приложение становится стильное и современное. С другой стороны инди разработчик тоже не сможет даже придумать такой интерфейс который ты скинул, а денег нанимать дизайнера на такие дела просто нет!
CS>через пару лет тебе нужно будет твой UI переделать на более современные стили. CS>Причем глобально, т.е. все <input type=text> у тебя должны будут иметь "белый верх, красный низ".
Ни один мой пользователь за 10 лет не попросил новый интерфейс.Зато есть куча примеров когда пользователи плевались новым дизайном. Взять хотя бы офис.
CS>Что ты будешь делать со своим "визуальным дизайнером" которого уже в природе может и не быть к тому времени ?
Здравствуйте, C0x, Вы писали:
C0x>MFC уже сколько лет? А он ещё и развивается!
Да помер он уже давно. MFC был еще как-то актуальным лет 20 назад. Когда он был фреймоворком MS Office (т.е. 25 лет назад). И когда рынок его компонентов приносил хоть какие-то деньги.
Теперь это удел маргиналов.
Никто в здравом уме что-то новое с ним уже не начинает.
на новой работе есть какое-то маленькое старое приложение на knockout и jquery, поковырялся в нём: ну, вообщем, всё там понятно, но подташнивает...
на старой работе кумары писали фронтенд на ангуляре, тоже туда иногда заглядывал, но там и подташнивало и одновременно смешно было,
недавно видел очередной killer mvvm framework, когда написанное на C# переводится на javascript/html, они вроде как хотят еще и реакт и blazor туда прикрутить, но сеё автоматически нагенерированное чудо не отлаживается, ну да ни суть, подобного полно: и внутри и снаружи это говно выглядит одинаково убого
может, со временем придёт на работу поколение Z или какое там, которое ничего кроме фейсбуков и снэпчатов в своей недолгой жизни не видело: они не смогут работать с большим количеством контролов, так как оно не будет помещаться в их голову, может, они и сейчас уже постепенно приходят, по идее, для них ничего , кроме одной кнопки на форме и не надо, всё само собой на формочках должно заполняться, а пользователь лишь кликает, что типа "согласен, дальше", для такого яваскрипт — самое то
Здравствуйте, takTak, Вы писали:
C>>JS+HTML T>сколько можно повторять набившие оскомину мантры?
Тем не менее.
T>на новой работе есть какое-то маленькое старое приложение на knockout и jquery, поковырялся в нём: ну, вообщем, всё там понятно, но подташнивает...
Прямо как WPF! Впрочем нет, от WPF ещё и понос дизентерийный начинается.
Для JS сейчас уйма вариантов, Knockout+Jquery — это примерно 10-летняя давность. Нынешние подходы позволяют легко делать приложения, которые масштабируются от телефонов до компьютеров. Или генерировать интерфейс декларативно на основе структуры данных.
Или пойти в другую сторону и рисовать элементы управления самому до последнего пикселя.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Говорят будет нативный список с виртуализацией (может быть, когда-нибудь) — то что во всех вменяемых GUI фреймворках есть с рождения. Пока предлагают пользоваться джава скриптовыми реализациями ЕА>>которых куча и надо самому выбрать нормально работающую и интегрировать в свой фреймворк: C>И шо? Давно известно, что на JS надо всё самому делать (точнее, подключать нужную библиотеку). Типа: https://akryum.github.io/vue-virtual-scroller/#/dynamic
Ну то есть самый-самый типовой сценарий, который есть из коробки во всех GUI библиотеках и работает предсказуемым образом, здесь "надо делать самому" подключая 3rd party библиотеки, которые наверняка придется тестировать на самому на производительность и совместимость. И так с кучей важных фич. В 2018 году.
Вот чем это лучше, чем установить одно свойство в WPF?
C>Что гораздо лучше поможет — это поддержка shadow DOM во всех браузерах. С ним уже можно делать полностью плавную анимацию без всяких задержек, даже при необходимости тяжёлых элементов управления.
ЕА>>А еще говорят многопоточность будет (когда-нибудь, и если пишешь на веб-ассембли) C>Это сильно обманчивая новость. Рендеринг HTML+CSS в браузерах уже давно многопоточный и аппаратно-ускоренный, такого в WPF не осилили до сих пор. Однопоточным является выполнение скриптов.
Ну а мне надо в моем коде. Что делать мне делать, имея в наличии "самую совершенную платформу"?
Здравствуйте, Cyberax, Вы писали:
ЕА>>А еще говорят многопоточность будет (когда-нибудь, и если пишешь на веб-ассембли) C>Это сильно обманчивая новость. Рендеринг HTML+CSS в браузерах уже давно многопоточный и аппаратно-ускоренный, такого в WPF не осилили до сих пор.
В UWP осилили, а это тот же WPF, вид в профиль.
Там события мыши/клавы обрабатываются в одном потоке, ресолвинг атррибутов композиции происходит в другом, ну а драйвер 3D шлёт сцену в картейку в третьем.
В браузере ведь "движок" отделён от остальных подсистем?
Так же и в архитектурах а-ля WPF.
Здравствуйте, vdimas, Вы писали:
V>Там события мыши/клавы обрабатываются в одном потоке, ресолвинг атррибутов композиции происходит в другом, ну а драйвер 3D шлёт сцену в картейку в третьем. V>В браузере ведь "движок" отделён от остальных подсистем?
Нет. В браузере нынче сцена рендерится параллельно. Т.е. расчёт стилей элементов, их границ и т.д.
Здравствуйте, Евгений Акиньшин, Вы писали:
C>>И шо? Давно известно, что на JS надо всё самому делать (точнее, подключать нужную библиотеку). Типа: https://akryum.github.io/vue-virtual-scroller/#/dynamic ЕА>Ну то есть самый-самый типовой сценарий, который есть из коробки во всех GUI библиотеках и работает предсказуемым образом, здесь "надо делать самому" подключая 3rd party библиотеки, которые наверняка придется тестировать на самому на производительность и совместимость. И так с кучей важных фич. В 2018 году.
Я использовал виртуальный скроллинг ещё 5 лет назад без особых проблем. API в JS был абсолютно очевидный и тестирование тоже проблем не составляло.
Единственная сложность было — сделать возможность давать ссылки на элементы в списке. Но для WPF это вообще невозможно.
ЕА>Вот чем это лучше, чем установить одно свойство в WPF?
Тем, что в WPF придётся устанавливать свойства. Потом ещё. Потом ещё. Затем делать хаки. Затем оно будет тормозить.
C>>Это сильно обманчивая новость. Рендеринг HTML+CSS в браузерах уже давно многопоточный и аппаратно-ускоренный, такого в WPF не осилили до сих пор. Однопоточным является выполнение скриптов. ЕА>Ну а мне надо в моем коде. Что делать мне делать, имея в наличии "самую совершенную платформу"?
Использовать обработку на серверной стороне, очевидно.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, novitk, Вы писали:
N>>До того момента, когда стали популярны реактивные js-фреймворки, электроны и прочие QtQuick. В общем очередной легаси-фреймворк для легаси-языка, используемого в легаси-проектах. От опенсорсинга будет ни жарко ни холодно.
S>Вот уж WebAssembly и Blazor на подходе...
Так Qt уже умеет WebAssembly. Да и вообще они далеко замахнулись, но боюсь что будет как с QBS — не пропихнут из-за плохого маркетинга.
Впрочем, у того же Qt есть огромная ниша, куда .net+WPF не влезут — это embedded разработка.
Здравствуйте, Cyberax, Вы писали:
C>>>Это сильно обманчивая новость. Рендеринг HTML+CSS в браузерах уже давно многопоточный и аппаратно-ускоренный, такого в WPF не осилили до сих пор. Однопоточным является выполнение скриптов. ЕА>>Ну а мне надо в моем коде. Что делать мне делать, имея в наличии "самую совершенную платформу"? C>Использовать обработку на серверной стороне, очевидно.
Чтобы сделать было дороже, медленнее и не работало в оффлайне?
Хороший совет, но я подожду потоков в wasm
Здравствуйте, novitk, Вы писали:
T>>и сколько из проектов реализуются в штатах, а не где-то между калькуттой и даккой? N>Проекты глобальные. ~80% кода идет из Нью-Йорка, Лондона, Токио, Сингапура и Гонконга.
Ну да, пастухи-надсмотрщики там, да. А вот овцы больше во всяких бангалорах. И только особо преданных могу забрать в метрополию на H1B.
Здравствуйте, koandrew, Вы писали:
K>Какие нафиг политики — я уже из трёх проектов выпилил нафиг этот кусок серой субстанции! Хуже компонентов я ещё не встречал, а их саппорт вообще состоит из клинических идиотов
И что вместо него?
Здравствуйте, Sharov, Вы писали:
C>>Он означает, что UI невозможно нормально положить в репозиторий и работать над ним нескольким людям. S>Это почему,в чем проблема хранить XML в git репозитории? Нормально
Здравствуйте, Sharov, Вы писали:
C>>Диффы от UI-билдера будут нечеловекочитаемы. S>В чем проблема сравнить два xml файла? Пример нечитаемости можно?
Небольшие изменения могут сломать структуру (если редактор переупорядочит элементы).
Ещё проблема в том, что если делать масштабируемые формы, то визуальный редактор уже начинает даже и мешать. Так как не видно структуры (что куда масштабируется).
Здравствуйте, Cyberax, Вы писали:
C>Небольшие изменения могут сломать структуру (если редактор переупорядочит элементы).
C>Ещё проблема в том, что если делать масштабируемые формы, то визуальный редактор уже начинает даже и мешать. Так как не видно структуры (что куда масштабируется).
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, vdimas, Вы писали:
V>>Или если требуется ембеддить OLE-документы друг в друга, то сегодня альтернативы MFC на эту часть проекта нет.
I>Вырожденый сценарий. В веб решениях аналогичная механика делается на коленке
Нука, засунь OLE-документ друг в друга в своем веб решении.
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, Эйнсток Файр, Вы писали:
_>Если бы MS изначально сделала WPF кроссплатфоменным фрейворком, то у него были бы шансы на жизнь, а так нет. Сейчас больше пользователей не на винде.
за последние 20 лет ява для десктопа абсолютно не смогла ничего представить, т.е. абсолютно ничего, её там и нет,
единственный конкурент для .net , как это и было все последние 15 лет — это c++
Здравствуйте, takTak, Вы писали:
E>>В этом нет смысла, т. к. есть Java
T>за последние 20 лет ява для десктопа абсолютно не смогла ничего представить, т.е. абсолютно ничего, её там и нет, T>единственный конкурент для .net , как это и было все последние 15 лет — это c++
Сейчас на десктопе основной конкурент это JS, именно на него переписывают многие приложения.
T>>единственный конкурент для .net , как это и было все последние 15 лет — это c++
I>Сейчас на десктопе основной конкурент это JS, именно на него переписывают многие приложения.
ни одного такого приложения сам своими глазами не видел
недавно, кстати, узнал что изначально написанный на яваскипте Azure Storage Explorerбыл переписан на C# (Blazor + Electron.NET)
яваскрипт, "давай, досвиданья"
Здравствуйте, takTak, Вы писали:
T>>>единственный конкурент для .net , как это и было все последние 15 лет — это c++ I>>Сейчас на десктопе основной конкурент это JS, именно на него переписывают многие приложения. T>ни одного такого приложения сам своими глазами не видел
Ну так надо вылезать из своей норы.
См.: Slack, VisualStudio Code, Atom, ....
T>недавно, кстати, узнал что изначально написанный на яваскипте Azure Storage Explorerбыл переписан на C# (Blazor + Electron.NET) T>яваскрипт, "давай, досвиданья"
Ага, только вот он не на WPF сделан. То что JS неудобен как голый язык — давно известно. Как и то, что браузер уже победил все альтернативы.
Здравствуйте, novitk, Вы писали:
N>Я говорю именно о разрабах, а не о менеджменте. Бангалор и пастухи-мэнеджеры используется конечно для перефирии, но не для ключевых компонентов.
T>ну, кстати, я помню интервью с кем-то из тех, кто WPF проектировал: он открыто признал, что помешанность на XML была ошибкой, хотя когда они библиотеку проектировали, наверное, никакого json и в помине не было T>в WPF полно и других штук типа Multiple/Ancestor/ Parent / Style Trigger Inheritance: там , конечно, столько всего наворочено, что вряд ли найдётся кто-то, кто все эти взаимосвязи может быстро отследить
Первая версия css появилась в 1996 году, за 10 лет до выхода WPF. Multiple/Ancestor/ Parent / Style Trigger Inheritance — именно, что слишком наворочено, в css три прозрачных уровня видимости стиля и все.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, hi_octane, Вы писали:
_>>Так что те кто херачил код — молодцы. А вот те кто утвердил XAML на десятилетия — облажались.
S> Ну а что вместо Xaml? Одно время конфиг файлы для .Net Core были на Json. Сразу было огромная куча критики на это примитивный формат. S>Обратно вернули на Xml.
Э... вот тут не прав. Конфиги на json'e хороши тем, что ты конфигурируешь все в одном формате и для клиентского приложения, и для rest api на asp.net core. Лучше безобразно, но единообразно :)
Здравствуйте, Serginio1, Вы писали:
S> При этом в WPF ты ни строчкт не пишешь, а используешь визульный редактор.
Необходимость использовать визуальный редактор для простейших стилей — это есть скорее всего попытка скрыть лажу в оверхеде. Я могу css и html накидать хоть в блокноте.
И это мощный плюс...
Здравствуйте, takTak, Вы писали:
I>>Сейчас на десктопе основной конкурент это JS, именно на него переписывают многие приложения.
T>ни одного такого приложения сам своими глазами не видел
Скайп. SQL Management Studio.
T>недавно, кстати, узнал что изначально написанный на яваскипте Azure Storage Explorerбыл переписан на C# (Blazor + Electron.NET) T>яваскрипт, "давай, досвиданья"
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, white_znake, Вы писали:
_>>Подозрение, что квалификация WPF разработчика — senior, а js + html + css — ниже? K>Учитывая скорость появления и умирания говнофреймворков на js, как там вообще могут быть сеньоры? :)))
Ты просто не можешь аргументировано спорить. То, что html, css, js развиваются (ну да, старые фреймворки умирают, новые появляются) — это наоборот хорошо. А то, что WPF так и застыл на уровне 2000-х — это ни есть плюс, а скорее минус.
_>>Просто когда используешь уверенно все фишки html5 + css3, то аналогичные вещи можно сделать написав меньше кода, чем на WPF. K>Бред.
Не бред, просто посмотри стиль для кнопки на html5 + css3 и аналогичный стиль в XAML. В XAML букв будет больше :)
_>>А какие причины для отстрела ноги в js + html + css? K>Рукожопие в связи с новизной очередного говнофреймворка (который кстати школохипстеры объявят "немодным" и obsolete до того, как ты успеешь завершить проект), помноженное на феноменальную убогость тулчейна и самого языка.
Ни кто не заставляет тебя делать продукт на самой первой версии фреймворка.
Я сам не стал изучать Angular1, потому что решил подождать, когда выйдет вторая версия, и не прогадал.
P.S. А в WPF пофиксили необходимость костылей для натягивания MVVM на popups? Или до сих пор "магия" нужна?
Здравствуйте, white_znake, Вы писали:
_>Э... вот тут не прав. Конфиги на json'e хороши тем, что ты конфигурируешь все в одном формате и для клиентского приложения, и для rest api на asp.net core.
Здравствуйте, IID, Вы писали:
_>>Это ты вообще о чём? Там же есть lgpl лицензия, которая практически свободная. IID>1) Конечно же не свободная
Не вижу никаких реальных ограничений.
IID>2) Очень много компонентов в неё не входят
Да, если абсолютно необходимы компоненты подходящие только под коммерческую лицензию, то тогда действительно проблема.
IID>3) смешивать коммерческую и открытую лицензию запрещено IID>Собс-но нет (не было) проблемы купить коммерческую лицензию, НО! IID>- запрет поставлять своё ПО, если лицензия закончилась. Даже если разработка уже давно не ведётся. Просто продаём готовое со склада. IID>- самое мерзкое: необходимость покупать "рантаймы". Минимум 5000 штук!
Тут согласен. Qt есть смысл использовать по LGPL или вообще не использовать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
_>>>Что там по кол-ву буковок? S>> При этом в WPF ты ни строчкт не пишешь, а используешь визульный редактор. C>Визуальный редактор — это огромный анти-паттерн. Он означает, что UI невозможно нормально положить в репозиторий и работать над ним нескольким людям.
Почему? Чем он хуже ручного ввода? C>И при этом он не сокращает время разработки, совсем.
Поверь сокращает как и интеллисенс
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, hi_octane, Вы писали:
_>>>Так что те кто херачил код — молодцы. А вот те кто утвердил XAML на десятилетия — облажались.
S>> Ну а что вместо Xaml? Одно время конфиг файлы для .Net Core были на Json. Сразу было огромная куча критики на это примитивный формат. S>>Обратно вернули на Xml. _>Э... вот тут не прав. Конфиги на json'e хороши тем, что ты конфигурируешь все в одном формате и для клиентского приложения, и для rest api на asp.net core. Лучше безобразно, но единообразно
Ну вот в итоге то и выбрали Xml
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, SaZ, Вы писали:
_>>Это ты вообще о чём? Там же есть lgpl лицензия, которая практически свободная. SaZ>Она не работает, если вы поставляете hardware без возможности заменить используемый там Qt на свой собственный. Никто не будет заморачиваться и вставлять в кофеварку порты для апдейта версии кутэ. Не говоря уже о том, что если собирать всё в статике с использованием QtLite вам будет нереально вписаться в lgpl. Собственно Qt на этом и делает деньги. Многие автопроизводители сейчас используют Qt.
А, ну если с железом поставляемое, то там действительно проблема. Кстати, у нас тут тоже железо имеется, но в нём Qt не используется.
SaZ>А для десктопа да — одно удовольствие, можно юзать бесплатно и продавать.
Мы используем для десктопа и мобилок.
SaZ>Пока достойных аналогов для C++ нет и не предвидится.
Если только для десктопа брать, то wxWidgets получше пожалуй. Но нам надо и мобилки сразу (в одном приложение), так что особого выбора нет — только эта жирненькая и устаревшая с точки зрения современного C++ библиотека подходит.
Здравствуйте, IID, Вы писали:
IID>2) Очень много компонентов в неё не входят
"Много" это сильное преувеличение, но да, вкусняшки для embedded они специально в LGPL не включили.
IID>- запрет поставлять своё ПО, если лицензия закончилась. Даже если разработка уже давно не ведётся. Просто продаём готовое со склада. IID>- самое мерзкое: необходимость покупать "рантаймы". Минимум 5000 штук!
Это Qt for Device Creation, для обычной версии таких ограничений нет.
Здравствуйте, alex_public, Вы писали:
C>>Ещё проблема в том, что если делать масштабируемые формы, то визуальный редактор уже начинает даже и мешать. Так как не видно структуры (что куда масштабируется). _>Это каким это образом структура формы может быть видна в коде и при этом будет не винда в визуальном редакторе? )))
Если в WPF есть спецрежим отладочный, отображающий на форме допинформацию, то, наверное, его не просто так сделали?
T>скайп, как я тут уже написал раннее, стал, скорее антирекламой электрона, и тут только с этого форума несколько человек со мной согласны
Да, форум это показатель!
T>про SQL Management Studio — интересно, какая имеется в виду? вот посмотрел на ту версию, что у меня на компе: SQL Server 2016 13.0.16106.4, она вроде никак ни с каким яваскриптом не связана, или ?
Здравствуйте, white_znake, Вы писали:
_>Необходимость использовать визуальный редактор для простейших стилей — это есть скорее всего попытка скрыть лажу в оверхеде. Я могу css и html накидать хоть в блокноте. _>И это мощный плюс...
А вот то что для html нельзя сделать нормальный визуальный редактор — еще более мощный минус
T>>скайп, как я тут уже написал раннее, стал, скорее антирекламой электрона, и тут только с этого форума несколько человек со мной согласны
I>Да, форум это показатель!
T>>про SQL Management Studio — интересно, какая имеется в виду? вот посмотрел на ту версию, что у меня на компе: SQL Server 2016 13.0.16106.4, она вроде никак ни с каким яваскриптом не связана, или ?
I>Попутал. Microsoft SQL Operations Studio
какая-никакая, но статистика, 7:1
7 человек считают, что скайп в новой версии стал говном хуже, один человек несогласен
Microsoft SQL Operations Studio !? WTF ! я даже не знаю, о чём ты говоришь... то что подавляющее большинство используeт- SQL Management Studio, что до сих пор на c++ /wpf
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>>>> Ну а что вместо Xaml? НС>>>http://www.ammyui.com/ S>> Ну это сахар. Внутри то все равно xaml
НС>Але, речь шла конкретно про XML, которого в ammy нет.
В ammy то нет, а в Xamarin.Forms есть. Я так понял Суть ammy в программном создании компонентов или создании Xaml
Ammy code is actually compiled to XAML. This means that any complex thing you could do in XAML you can also do with Ammy. Which would be much easier, thanks to concise syntax and mixins.
Например Json не поддерживает кучу конструкций Xaml. Насколько ammy перекрывает Xaml?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, takTak, Вы писали:
T>Microsoft SQL Operations Studio !? WTF ! я даже не знаю, о чём ты говоришь... то что подавляющее большинство используeт- SQL Management Studio
SSMS только под венду, так что на всяких линуксах альтернативы operations studio нет.
Здравствуйте, hi_octane, Вы писали:
_>Хотя вундервафля по своему устройству, имхо, долгое время подходила для написания браузеров хуже наверное всех языков на свете. Чего стоят только проблемы с такой базовой структуркой данных как дерево. Это в 2018-м году, через 3 года после релиза. Ёлки-палки, да браузер это сплошная работа с вложенными структурами которые перекрёстно ссылаются друг на друга.
Там же всё просто: After NLL: Moving from borrowed data and the sentinel pattern
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Я говорю именно о разрабах, а не о менеджменте. Бангалор и пастухи-мэнеджеры используется конечно для перефирии, но не для ключевых компонентов.
НС>Что там насчет пруфлинка?
Ты это серьезно?
Здравствуйте, alex_public, Вы писали:
_>Мы используем для десктопа и мобилок.
Не занимался вопросом лицензирования. Но под мобилки там достаточно толерантная платная версия, насколько я помню. Критично для iOS.
SaZ>>Пока достойных аналогов для C++ нет и не предвидится. _>Если только для десктопа брать, то wxWidgets получше пожалуй. Но нам надо и мобилки сразу (в одном приложение), так что особого выбора нет — только эта жирненькая и устаревшая с точки зрения современного C++ библиотека подходит.
Не холивара ради, но учитывая простоту разработки собственных виджетов, практически полное отсутствие необходимости костылей под платформы, а самое главное — документацию и комьюнити, wxWidgets тихо курит в сторонке. Ну и чисто субьективно — код Qt куда более прозрачный и понятный.
Это всё не говоря о том, что в Qt помимо GUI есть очень много чего полезного.
Здравствуйте, SaZ, Вы писали:
_>>Мы используем для десктопа и мобилок. SaZ>Не занимался вопросом лицензирования. Но под мобилки там достаточно толерантная платная версия, насколько я помню. Критично для iOS.
Да, там платная версия нормальная, но и lgpl вполне хватает (если не нервничать из-за известной двухсмысленности этой лицензии по поводу статической линковки).
SaZ>>>Пока достойных аналогов для C++ нет и не предвидится. _>>Если только для десктопа брать, то wxWidgets получше пожалуй. Но нам надо и мобилки сразу (в одном приложение), так что особого выбора нет — только эта жирненькая и устаревшая с точки зрения современного C++ библиотека подходит. SaZ>Не холивара ради, но учитывая простоту разработки собственных виджетов, практически полное отсутствие необходимости костылей под платформы, а самое главное — документацию и комьюнити, wxWidgets тихо курит в сторонке.
Вообще то концептуально вся Qt — это один большой "костыль", т.к. занимается самостоятельно прорисовкой всех контролов, мимикрируя под нативный вид платформы с помощью соответствующих (создаваемых по информации из системы) стилей. И на 99,9% у неё это отлично получается, так что многие даже не догадываются, что это не системные контролы.
А вот wxWidgets использует исключительно контролы системы (если они есть — если нет, то дорисовывает свои, но на современных ОС это уже редкость), так что интерфейс нативный на 100%. Причём тут важно не только то, что он выглядит всегда как надо, но и поддержка различных системных вещей (типа удалённого десктопа, инструментов для инвалидов и т.п.).
Но с Андроидом у концепции wxWidgets случился очевидный провал, т.к. там родной GUI доступен только из Java кода, а в нативном коде доступна только поверхность с OpenGL. И естественно, что сюда концепция Qt легла просто отлично. А т.к. Андроид является самой популярной ОС на планете в данный момент, то по сути у C++ приложения с GUI почти нет выбора (ну есть ещё некоторые лёгкие OpenGL GUI библиотеки типа nanogui, но их ещё надо долго дорабатывать до промышленного применения) — только Qt.
SaZ>Ну и чисто субьективно — код Qt куда более прозрачный и понятный.
Qt написана в ужасном Java стиле, полностью противоречащем стилю современного C++ (который можно увидеть в STL или Boost'е). Да, в последние пару лет они начали процесс движения правильную сторону, но реально на это потребуются десятилетия.
SaZ>Это всё не говоря о том, что в Qt помимо GUI есть очень много чего полезного.
От Qt интересен только GUI, т.к. всё остальное есть во множестве других библиотек (в первую очередь в Boost'е) и в намного более высоком качестве.
T>SOAP как стандарт был закреплён в 2000, .NET 1.1 вышел в 2003; наверное, в это же время уже началось проектирование WPF, менеджерам , по-твоему, надо было ориентироваться не на существовавший W3C стандарт, а на твои хотелки из 2018 года? не слишком ли жирно будет?
Думать на пару шагов вперёд никогда не жирно. И SOAP это, извините, стандарт обмена сообщениями между компами. Т.е. выбор его как основы для декларативного описания интерфейса людьми это прям что-то странное. Т.е. если такое выбирать, то с серьёзным лицом анализировать список вариантов, в котором рядом и ASN.1, и все остальные такие-же нечеловеческие
T>или ты сможешь найти твои вопли негодования по данному поводу(XAML\XML) в интернете от 2003 года? сейчас их можно найти, если таковые , на самом деле, были
Увы, с развитием поисковиков я вообще ничего найти не могу. Так что в этом месте позорно проигрываю. Но, хочу отметить, что джависты на тот момент уже перепробовали всё что можно в xml-конфигах, включая не только декларативные, но и императивные конструкции типа <if> , и просто подняв вопрос на их форуме можно было бы критику получить в кратчайшие сроки.
Здравствуйте, c-smile, Вы писали:
CS>Для эффективной параллельной обработки "стилей элементов, их границ и т.д." этот самый browser должен реально захватить всю машину — все её cores. Иначе это сплошные context switches. CS>Т.е. больше ничего не делать полезного кроме как рисовать UI на том бедном PC. Это путь в никуда.
Но реально получается. Насколько я понимаю, они используют его для достаточно крупных блоков.
CS>И с этим мы уже наелись. Вариант Node.js обработки в одном потоке против multi-threading обработки как тому подтверждение.
Это не подтверждение, в Node.JS просто нельзя делать многопоточность, даже если хочется.
CS>Mozilla со своими идеями вообще загнется в скорости. Не потому что её съедят, а потому что сначала делать язык чтобы на нем написать потом browser это путь через задницу, простите мой французский.
По факту, они сейчас соперничают с Chrome.
CS>Да и проблема которую решает Rust (утечки памяти) она надуманна, я её не понимаю если честно. Во всяком случае то что можно в C++ сделать просто культурой кода не стоит тех титанических усилий.
Rust так же позволяет не допускать (в принципе) висящих ссылок и гонок по данным.
CS>То что MS взяла за основу WebKit, а не Servo как бэ намекает. Уж у MS опыта работы со всякими managed решениями хватат по самы помидоры.
Хромиум сделан так, что его легко включать.
Здравствуйте, hi_octane, Вы писали:
_>Гикам и всяким фанатикам "написать браузер на C++ по стандартам кодирования" ты просто не продашь. Аккуратно писать на C++ это обычно не весело нифига, и нет никакой особой репутации или чувства приобщения к элите. Если на C++ развивать старый движок, с тоннами легаси, в то время как рядом с ураганной скоростью развивается хром — так и вообще, год работы даст меньше пафоса чем один принятый коммит в хром.
Можно показать мне с какой скоростью Хром развивается? Я пока реально не вижу каких-то фундаментальных улучшений.
В FireFox появился Quantum CSS и была переработана большая часть движка за последние пару лет.
Здравствуйте, Serginio1, Вы писали:
C>>Визуальный редактор — это огромный анти-паттерн. Он означает, что UI невозможно нормально положить в репозиторий и работать над ним нескольким людям. S>Почему? Чем он хуже ручного ввода?
В коде проще смотреть структуру. Вдобавок, при ручном вводе код получается человеческим.
C>>И при этом он не сокращает время разработки, совсем. S>Поверь сокращает как и интеллисенс
Я пробовал, по сравнению с HTML+JS — разницы нет.
Здравствуйте, c-smile, Вы писали:
CS>Да и проблема которую решает Rust (утечки памяти) она надуманна, я её не понимаю если честно. Во всяком случае то что можно в C++ сделать просто культурой кода не стоит тех титанических усилий.
Да, с помощью "культуры". Например, если бы все бородатые плюсисты вымерли, то можно было бы разрабатывать на D, не оглядываясь на аргумент "специалистов-то нет!"
CS>То что MS взяла за основу WebKit, а не Servo как бэ намекает. Уж у MS опыта работы со всякими managed решениями хватат по самы помидоры.
Дело в том, что Наделле надо в его копчёную лысину вкрутить шуруп. И тогда они перестанут заниматься аутсорсом критически важных вещей, вроде собственного движка браузера.
_>>Гикам и всяким фанатикам "написать браузер на C++ по стандартам кодирования" ты просто не продашь. Аккуратно писать на C++ это обычно не весело нифига, и нет никакой особой репутации или чувства приобщения к элите. Если на C++ развивать старый движок, с тоннами легаси, в то время как рядом с ураганной скоростью развивается хром — так и вообще, год работы даст меньше пафоса чем один принятый коммит в хром.
C>Можно показать мне с какой скоростью Хром развивается? Я пока реально не вижу каких-то фундаментальных улучшений.
Так Мозилла не сейчас зашевелилась, а когда хром начал проникать везде и всюду. Открой историю коммитов хрома с 2010-го и найди там то что важно лично тебе.
C>В FireFox появился Quantum CSS и была переработана большая часть движка за последние пару лет.
Ну этим переписыванием они решали свои проблемы. Не проблемы пользователя. Может как всё перепишут, потом повторят всё что есть в хроме, а потом начнут уходить вперёд — мы увидим что Файрфокс по фичам начал уделывать хром. Но пока совсем не факт.
Здравствуйте, novitk, Вы писали:
N>>>Я говорю именно о разрабах, а не о менеджменте. Бангалор и пастухи-мэнеджеры используется конечно для перефирии, но не для ключевых компонентов. НС>>Что там насчет пруфлинка? N>Ты это серьезно?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Кривейшая хрень. Одно время пришлось несколько контролов оттуда взять. Но потом, после рабочего прототипа, пришлось все взятое переписать.
Я оттуда юзаю BusyIndicator, т.к. лень было ваять свой в своё время А так обхожусь родными + самописными.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тем что они генерят кривой html. Нормальный html написать — даже для человека серьезная задача, требующая большого и специфического опыта, и правильного мышления. WPF в этом плане сильно дружелюбнее.
Причём в разное время понятие "нормального" бывает сильно разным. Я ещё помню табличную вёрстку
Здравствуйте, hi_octane, Вы писали:
C>>В FireFox появился Quantum CSS и была переработана большая часть движка за последние пару лет. _>Ну этим переписыванием они решали свои проблемы. Не проблемы пользователя.
А какие проблемы пользователя решают последние версии Chrome? Я чего-то нового там давно не припоминаю. Новые стандарты оба браузера поддерживают примерно ровно.
Чем конкретно отличается FF? Они сделали редизайн движка, механизма расширений, улучшили производительность — всё это важно для пользователей.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>>>Я говорю именно о разрабах, а не о менеджменте. Бангалор и пастухи-мэнеджеры используется конечно для перефирии, но не для ключевых компонентов. НС>>>Что там насчет пруфлинка? N>>Ты это серьезно? НС>То есть ты все придумал. ЧТД.
Странные у тебя фантазии. А зачем мне это придумывать?
Даже интересно стало.... А все эти истории про программеров в финансах NYC/LDN гребущие деньги лопатой тоже вранье или они все "пастухи-мэнеджеры"?
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, Serginio1, Вы писали:
S>>Например Json не поддерживает кучу конструкций Xaml. Насколько ammy перекрывает Xaml?
J>На 100% он покрывает xaml. И не понятно что значит "Json не поддерживает кучу конструкций Xaml"
Например комментарий, свой форматер для дат https://rsdn.org/forum/flame.comp/6249488.hot
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>>>Визуальный редактор — это огромный анти-паттерн. Он означает, что UI невозможно нормально положить в репозиторий и работать над ним нескольким людям. S>>Почему? Чем он хуже ручного ввода? C>В коде проще смотреть структуру. Вдобавок, при ручном вводе код получается человеческим.
Я вот код набирая всегда пользуюсь интеллисенсом и форматированием и с ужасом смотрю кто этим не пользуется
C>>>И при этом он не сокращает время разработки, совсем. S>>Поверь сокращает как и интеллисенс C>Я пробовал, по сравнению с HTML+JS — разницы нет.
Даа? Тот же ангулар, Блазор и разор позволяют использовать интеллисенс. И разница очевидна.
Но им ой как далеко до WPF
и солнце б утром не вставало, когда бы не было меня
J>Именно в ammy всё есть. Он использует json'о подобный, но не полностью совместимый с json язык.
Ну осталоcь, что бы MS сделала поддержку его например в Xamarin.Forms
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, white_znake, Вы писали:
_>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная. Подключение стилей в css, тоже более понятно, ни каких статический / динамических словарей.
Если посмотреть как они перекрываются то оочень непонятная
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, novitk, Вы писали:
НС>>>>Что там насчет пруфлинка? N>>>Ты это серьезно? НС>>То есть ты все придумал. ЧТД. N>Странные у тебя фантазии. А зачем мне это придумывать?
Да просто Ночной Смотрящий предпочитает жить в своём уютном воображаемом мирке. И если вдруг где-то встречается информация, противоречащая его воззрениям (а отказ кого-то от .net однозначно относится к такой категории), то она тут же классифицируется им как "лживые нападки ненавистников".
Самое забавное, что если бы ты вдруг каким-то образом всё же предоставил ссылку в доказательство своих слов, то это ничего не изменило бы. Он бы просто не стал её читать, а в ответе тебе стёр бы её из цитаты, сделав вид, что там ничего не было и продолжил бы обвинять тебя в выдумках.
Так что по своему опыту могу только посоветовать не тратить время на подобные дискуссии.
Здравствуйте, Serginio1, Вы писали:
S>>>Почему? Чем он хуже ручного ввода? C>>В коде проще смотреть структуру. Вдобавок, при ручном вводе код получается человеческим. S> Я вот код набирая всегда пользуюсь интеллисенсом и форматированием и с ужасом смотрю кто этим не пользуется
Ручной ввод, естественно, подразумевает автодополнение и прочие интеллисенсы.
S>>>Поверь сокращает как и интеллисенс C>>Я пробовал, по сравнению с HTML+JS — разницы нет. S> Даа? Тот же ангулар, Блазор и разор позволяют использовать интеллисенс. И разница очевидна. S>Но им ой как далеко до WPF
Причём тут вообще Intellisense? Речь идёт о сравнении с графическим редактором.
Здравствуйте, white_znake, Вы писали:
_>>>Чем тебе не нравятся существующие? НС>>Тем что они генерят кривой html. Нормальный html написать — даже для человека серьезная задача, требующая большого и специфического опыта, и правильного мышления. WPF в этом плане сильно дружелюбнее. _>Ну да, проблема с WYSIWYG редакторами — большая.
И проблема эта вызвана тем, что html для этого непригоден. С другой стороны, Blend вполне себе рабочий инструмент. ЧТД.
_>Похоже с html у тебя не очень.
Скорее у тебя не очень. Но я рад что ты перешел от аргументов к личным наездам. Значит понял что не прав.
_> Я сам был таким, потратил недельку упорного труда
Недельку мало. Дзен где то через полгода появится. Так что продолай работать над собой.
_>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная.
НС>И проблема эта вызвана тем, что html для этого непригоден. С другой стороны, Blend вполне себе рабочий инструмент. ЧТД.
HTML — непригоден для создания UI?
Что я могу сказать, сейчас в вебе есть только HTML & CSS. Ни чего другого — нет.
А для винды до фига UI фреймворков, помимо WPF. Что как бы намекает :)
НС>Недельку мало. Дзен где то через полгода появится. Так что продолай работать над собой.
Бугага, я в html & css с 2013 :)
_>>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная.
НС>:facepalm:
Здравствуйте, alex_public, Вы писали:
_>... _>Вообще то концептуально вся Qt — это один большой "костыль", т.к. занимается самостоятельно прорисовкой всех контролов, мимикрируя под нативный вид платформы с помощью соответствующих (создаваемых по информации из системы) стилей. И на 99,9% у неё это отлично получается, так что многие даже не догадываются, что это не системные контролы.
Нормальное решение. Как я понимаю, в конечном счёте, если не делать кастомизацию через стили, то дёргаются наитивные функции типа винапишного DrawFrameControl. А то что на каждую кнопку не создаётся свой HWND — не вижу в этом проблемы.
_>А вот wxWidgets использует исключительно контролы системы (если они есть — если нет, то дорисовывает свои, но на современных ОС это уже редкость), так что интерфейс нативный на 100%. Причём тут важно не только то, что он выглядит всегда как надо, но и поддержка различных системных вещей (типа удалённого десктопа, инструментов для инвалидов и т.п.).
Кроме удалённого десктопа — не вижу причин использовать wxWidgets, а это очень редкий случай. Аксесебилити уже нормально поддерживается в Qt.
Зато сделать кастомный контрол на wxWidgets на порядок сложнее, чем на Qt.
Субьъективно для меня — ваши аргументы очень незначительны, относительно стоимости разработки на Qt.
Если уж сильно хочется — то пишется лёгкий клиент, который через remote objects работает с серверной частью.
SaZ>>Ну и чисто субьективно — код Qt куда более прозрачный и понятный. _>Qt написана в ужасном Java стиле, полностью противоречащем стилю современного C++ (который можно увидеть в STL или Boost'е). Да, в последние пару лет они начали процесс движения правильную сторону, но реально на это потребуются десятилетия.
Причём тут джава? Нормальный кодстайл. Главное, что весь фреймворк выдержан в едином стиле. Как внешние API, так и внутренности. Код реально легко читается, в отличие от того же буста (я знаю, почему буст такой, но тем не менее). В Unreal Engine тоже достаточно специфический кодстайл, но тем не менее он работает и работает эффективно.
SaZ>>Это всё не говоря о том, что в Qt помимо GUI есть очень много чего полезного. _>От Qt интересен только GUI, т.к. всё остальное есть во множестве других библиотек (в первую очередь в Boost'е) и в намного более высоком качестве.
Сигналы/слоты в Qt вообще вне конкуренции.
Интроспекцию в бусте я не трогал (а в Qt достаточно много), ничего не скажу, но слышал что с отладкой там ад, в отличие от Qt.
Не помню, чтобы в бусте были базы данных.
Или что-то удобное для работы с http (обычно все curl прикручивают или поверх asio что-то изобретают). Beast появился не так давно.
Или работа с изображениями (я не про GUI).
Не говоря о том, что если тянуть разные 3rdparty для всего этого добра, то придётся городить кучу проксей, чтобы всё это связать. А Qt умеет практически всё из коробки.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, white_znake, Вы писали:
_>>Ты просто не можешь аргументировано спорить. То, что html, css, js развиваются (ну да, старые фреймворки умирают, новые появляются) — это наоборот хорошо. А то, что WPF так и застыл на уровне 2000-х — это ни есть плюс, а скорее минус. K>:facepalm:
Меньше эмоций, юбольше аргументов.
K>Это хорошо только для короткоживущих говнопроектов хомячков. Ибо реальные приложения надо поддерживать годами, а то и десятилетиями. И "поддерживать" не значит постоянно переписывать на очередной говнофреймворк, которые хомячки объявили "крутым" в определённый момент времени.
Компания, в которой работал, занималась разработкой трейдингового софта с 90-х. в конце 2000-х выпустили клиента на WPF для трейдеров. Потом клиенты компании осознали, что еще больше бабок можно зарабатывать на хомячках, которые решили заработать на трейдинге. И решили заказывать трейдинговые клиенты, работающие через веб. После запуска веб-клиента, сами проф.трейдеры, работающие на клиентов компании, начали переходить с WPF версии на веб-версию.
А потом поступил заказ на разработку мобильной версии трейдингового клиента.
Так что тут мир и технологии меняются и заставляют меняться сами компании, до конца 2000-х широкополосной интернет был не у всех, так же не были распространены смарфтоны, поэтому большинство использовали десктопные приложения. С развитием широкополосного доступа, народ начал мигрировать в веб. Сейчас в мобилки.
Если ты один из разработчиков корпоративного приложения, которое ни куда не собирается мигрировать (нет смысла и все) — это не значит, что у всех такая же ситуация.
Я прошел путь от разработки клиентов на WInAPI, MFC, WPF до разработки веб клиентов на js (как на голом js, так и с использованием ангуляров и реактов) и до мобильной разработки (ionic, kotlin). О чем не жалею.
_>>Не бред, просто посмотри стиль для кнопки на html5 + css3 и аналогичный стиль в XAML. В XAML букв будет больше :) K>Мдя. Ты точно знаешь WPF?
Знаю ;)
Сравним:
_>>Ни кто не заставляет тебя делать продукт на самой первой версии фреймворка. _>>Я сам не стал изучать Angular1, потому что решил подождать, когда выйдет вторая версия, и не прогадал. K>Ты какая там нынче версия актуальна? ;)
Angular 6. Но начиная со второй — все обратно совместимы. Но я ни когда на первую версию фреймворка и не перехожу :)
_>>P.S. А в WPF пофиксили необходимость костылей для натягивания MVVM на popups? Или до сих пор "магия" нужна? K>Если руки растут из правильного места, то ничего никуда натягивать не нужно.
Ну может руки и были кривоваты тогда, а может уже забыл какие-то детали, т.к. с 2013 на WPF не пишу.
Здравствуйте, Cyberax, Вы писали:
S>> Даа? Тот же ангулар, Блазор и разор позволяют использовать интеллисенс. И разница очевидна. S>>Но им ой как далеко до WPF C>Причём тут вообще Intellisense? Речь идёт о сравнении с графическим редактором.
А то, что в WPF есть и графический редактор и Intellisense который тебе подскажет какие свйства выбирать, создаст методы по F12 итд.
Там что писать ручками очень мало нужно
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, white_znake, Вы писали:
_>Меньше эмоций, юбольше аргументов.
Это факты и есть.
_>Если ты один из разработчиков корпоративного приложения, которое ни куда не собирается мигрировать (нет смысла и все) — это не значит, что у всех такая же ситуация. _>Я прошел путь от разработки клиентов на WInAPI, MFC, WPF до разработки веб клиентов на js (как на голом js, так и с использованием ангуляров и реактов) и до мобильной разработки (ionic, kotlin). О чем не жалею.
Ну то есть я прав про короткоживущие говнопроектики. ЧТД
_>Знаю _>Сравним:
А как насчёт применения стиля только ко кнопкам, отображающую определённую команду? Тут уже внужен говноскрипт — а в WPF можно декларативно
_>Angular 6. Но начиная со второй — все обратно совместимы. Но я ни когда на первую версию фреймворка и не перехожу
ЧТД 2
_>Ну может руки и были кривоваты тогда, а может уже забыл какие-то детали, т.к. с 2013 на WPF не пишу.
ЧТД 3
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
CS>>Для эффективной параллельной обработки "стилей элементов, их границ и т.д." этот самый browser должен реально захватить всю машину — все её cores. Иначе это сплошные context switches. CS>>Т.е. больше ничего не делать полезного кроме как рисовать UI на том бедном PC. Это путь в никуда.
C>Но реально получается. Насколько я понимаю, они используют его для достаточно крупных блоков.
В абстрактном случае когда browser это единственная программа работающая на PC — да, что-то может ускорится, но не в разы.
Да и то, в то же самое время в потоках работает подкачка ресурсов, видео декодер, WebRTC, WebWorkers и прочая хрень.
На layout calculations в реальных условиях хорошо если хотя бы один core остается.
Весь этот multithread fuzz хорошо если не навредит в итоге. Если сильно повезет то 10% прибавит.
Здравствуйте, SaZ, Вы писали:
_>>Вообще то концептуально вся Qt — это один большой "костыль", т.к. занимается самостоятельно прорисовкой всех контролов, мимикрируя под нативный вид платформы с помощью соответствующих (создаваемых по информации из системы) стилей. И на 99,9% у неё это отлично получается, так что многие даже не догадываются, что это не системные контролы. SaZ>Нормальное решение. Как я понимаю, в конечном счёте, если не делать кастомизацию через стили, то дёргаются наитивные функции типа винапишного DrawFrameControl. А то что на каждую кнопку не создаётся свой HWND — не вижу в этом проблемы.
Основные инженерные минусы этого решения не в HWND:
— интерфейс конечно же выглядит нативно (Qt в этом смысле хороша, но за счёт чисто экстенсивных усилий), но всё же не на 100% (иногда проскальзывают отличия)
— огромная часть кода приложения занята банальном эмуляцией поведения ОС, на которой при этом исполняется. Т.е. просто глупо.
— не все функции ОС (это мы обсуждали уже ниже) работают с таким GUI.
_>>А вот wxWidgets использует исключительно контролы системы (если они есть — если нет, то дорисовывает свои, но на современных ОС это уже редкость), так что интерфейс нативный на 100%. Причём тут важно не только то, что он выглядит всегда как надо, но и поддержка различных системных вещей (типа удалённого десктопа, инструментов для инвалидов и т.п.). SaZ>Кроме удалённого десктопа — не вижу причин использовать wxWidgets, а это очень редкий случай. Аксесебилити уже нормально поддерживается в Qt.
Использовать wxWidgets для программирования GUI на десктопе стоит хотя бы потому, что там это можно делать на нормальном чистом C++, а не на неком сомнительном убожестве, требующем препроцессора.
SaZ>Зато сделать кастомный контрол на wxWidgets на порядок сложнее, чем на Qt.
С чего бы это? Сделать кастомный контрол было просто даже на банальном WinAPI. А уж на Qt и wxWidgets вообще по сути нет никаких отличий — наследуешься от нужного класса и рисуешь что хочешь. Только вот качественная GUI библиотека как раз и отличается тем, что там таким в большинстве случаев страдать не надо — есть уже готовый набор качественных контролов нативного вида.
SaZ>Субьъективно для меня — ваши аргументы очень незначительны, относительно стоимости разработки на Qt. SaZ>Если уж сильно хочется — то пишется лёгкий клиент, который через remote objects работает с серверной частью.
А откуда взялось мнение, что стоимость разработки (естественно если говорить про GUI для десктопа) у wxWidgets и Qt отличаются?
SaZ>>>Ну и чисто субьективно — код Qt куда более прозрачный и понятный. _>>Qt написана в ужасном Java стиле, полностью противоречащем стилю современного C++ (который можно увидеть в STL или Boost'е). Да, в последние пару лет они начали процесс движения правильную сторону, но реально на это потребуются десятилетия. SaZ>Причём тут джава? Нормальный кодстайл. Главное, что весь фреймворк выдержан в едином стиле. Как внешние API, так и внутренности. Код реально легко читается, в отличие от того же буста (я знаю, почему буст такой, но тем не менее). В Unreal Engine тоже достаточно специфический кодстайл, но тем не менее он работает и работает эффективно.
Я говорю не про оформление, а про архитектуру. В которой сплошные указатели, виртуальные функции, динамическая память, COW, позднее связывание и т.п. Это полностью противоречит современному C++, в котором отдаётся преимущество типам-значениям, семантики перемещения, статическому полиморфизму, шаблонам и т.п. Причём делается не из-за каких-то "вкусов", а из-за того, что такой код намного надёжнее и производительнее.
В последние несколько лет в Qt это осознали и начали постепенное движение в направление нормального C++. Например отказываются от своих контейнеров (которые как раз COW), в пользу STL (где типы-значения, оптимизированные семантикой перемещения), добавляют нормальное (прямое) связывание функций (в том числе и лямбд) с сигналами и т.д. и т.п. Но с учётом огромных размеров этого монстра, похожим на нормальный C++ он станет только через десятилетия таких усилий.
И да, всё вышеперечисленное оставляло за скобками такую дикую ересь, как специальный препроцессор, который для решения задач GUI библиотеки не нужен в принципе. Пока они от него не избавятся, говорить о нормальном C++ будет нельзя. Ну и кстати говоря, с учётом последних добавок к механизму связывания, это вполне можно было бы сделать, но к сожалению, не смотря на эти добавки, все их инструменты продолжают использовать старые механизмы.
SaZ>>>Это всё не говоря о том, что в Qt помимо GUI есть очень много чего полезного. _>>От Qt интересен только GUI, т.к. всё остальное есть во множестве других библиотек (в первую очередь в Boost'е) и в намного более высоком качестве. SaZ>Сигналы/слоты в Qt вообще вне конкуренции.
Это убогая динамическая хрень, корректность работы которой компилятор в принципе не способен проверить? Даже не смешно...
SaZ>Интроспекцию в бусте я не трогал (а в Qt достаточно много), ничего не скажу, но слышал что с отладкой там ад, в отличие от Qt.
Интроспекции в Бусте очевидно нет, т.к. её нет (до прихода стандарта C++23) в самом языке. То, что в Qt с помощью препроцессора делается некая динамическая (ужасно не эффективно с точки зрения языков типа C++) надстройка — это не преимущество, а недостаток.
SaZ>Не помню, чтобы в бусте были базы данных.
Я говорил не только про Boost.
SaZ>Или что-то удобное для работы с http (обычно все curl прикручивают или поверх asio что-то изобретают). Beast появился не так давно. SaZ>Или работа с изображениями (я не про GUI). SaZ>Не говоря о том, что если тянуть разные 3rdparty для всего этого добра, то придётся городить кучу проксей, чтобы всё это связать. А Qt умеет практически всё из коробки.
Да, умеет много чего из коробки. Но всё (кроме GUI) хреновенько так, на троечку, если сравнивать с отдельными профильными инструментами.
P.S. Забавно так спорить с фанатом Qt, хотя при этом я сам использую Qt для GUI всех своих проектов. ))) Только вот я осознаю, что делаю это от безысходности: Qt — ужасна, но ничего лучшего для GUI с такой же кроссплатформенностью нет.
Здравствуйте, white_znake, Вы писали:
НС>>И проблема эта вызвана тем, что html для этого непригоден. С другой стороны, Blend вполне себе рабочий инструмент. ЧТД. _>HTML — непригоден для создания UI?
Перечитай еще раз для чего он непригоден.
_>А для винды до фига UI фреймворков, помимо WPF. Что как бы намекает
Уга, намекает что ты споришь с голосами в голове.
НС>>Недельку мало. Дзен где то через полгода появится. Так что продолай работать над собой. _>Бугага, я в html & css с 2013
А я с 2001. Так что у меня все равно длинее, и мерянье можно заканчивать.
_>>>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная. НС>> _>А контраргумент?
А смысл, если ты про WPF ничего почти не знаешь? Все равно ведь не поверишь.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, white_znake, Вы писали:
_>>Меньше эмоций, юбольше аргументов. K>Это факты и есть.
_>>Если ты один из разработчиков корпоративного приложения, которое ни куда не собирается мигрировать (нет смысла и все) — это не значит, что у всех такая же ситуация. _>>Я прошел путь от разработки клиентов на WInAPI, MFC, WPF до разработки веб клиентов на js (как на голом js, так и с использованием ангуляров и реактов) и до мобильной разработки (ionic, kotlin). О чем не жалею. K>Ну то есть я прав про короткоживущие говнопроектики. ЧТД :facepalm:
Нет, не прав, чисто твои додумки. WPF клиент прожил с 2008 по 2012, в 2013 от него отказали окончательно. Веб клиент живет с 2012 по текущее время, живет и развивается.
Мобильный клиент живет с 2014.
Выводы сделаешь сам.
_>>Знаю ;) _>>Сравним: K>А как насчёт применения стиля только ко кнопкам, отображающую определённую команду? Тут уже внужен говноскрипт — а в WPF можно декларативно ;)
Что значит отображающую определенную команду? Может имел ввиду привязку к команде?
Задай стили в CSS:
Не менее декларативно :)
_>>Angular 6. Но начиная со второй — все обратно совместимы. Но я ни когда на первую версию фреймворка и не перехожу :) K>ЧТД 2
А ты переходил на .NET 1.0? И Silverlight небось использовал, при драфте html5 & css3? :)
НС>А смысл, если ты про WPF ничего почти не знаешь? Все равно ведь не поверишь.
Так же и могу сказать, что твои знания html скорее всего сильно уступают знаниям в WPF.
А я и не претендую сейчас на звание WPF разработчика. Я WPF использовал с 2008 по 2012 и его с тех пор не использовал.
У тебя скорее всего обратная ситуация, ты используешь WPF и десктоп, а html используешь на много реже вот и все выводы.
Потому для меня лучше HTML5 + CSS, для тебя лучше WPF.
Единственное, на WPF меньше вакансий, чем на html+css+js+(ASP.NET || ASP.NET Core || Node.js). Хотя могу ошибаться и ты мне докажешь обратное ;)
Здравствуйте, white_znake, Вы писали:
_>Выводы сделаешь сам.
Уже сделал. Мы поддерживаем системы по 10+ лет.
_>Что значит отображающую определенную команду? Может имел ввиду привязку к команде? _>Не менее декларативно
Я конечно понимаю, что жабаскриптистам некогда изучать паттерны — надо педалить, но паттерн "команда" вроде бы достаточно известен....
_>А ты переходил на .NET 1.0? И Silverlight небось использовал, при драфте html5 & css3?
Я использовал то, что имело смысл в конкретном проекте. С .NET начал работать с 1.0, но перешли на 1.1 ещё до того, как успели зарелизиться.
Здравствуйте, white_znake, Вы писали:
_>У тебя скорее всего обратная ситуация, ты используешь WPF и десктоп, а html используешь на много реже вот и все выводы.
Не угадал. Сейчас среди моих текущих проектов нет ни одного десктопа, исключительно веб уи. Именно поэтому я прекрасно знаю, какое ущербное Г этот ваш хтмл.
