Возможно тупая идея (я не пишу на C# годы), но мне бы хотелось иметь абсолютные ссылки
TextBlock {
viewmodel MyApp.SomeType
Text Absolute {TextBlockText}: bind PropertyFromViewModel
}
при этом в коде вне зависимости от того куда я перенесу данный фрагмент (в том числе и рантайм, в том числе и пользователь) ссылка на элемент всегда будет TextBlockText
Здравствуйте, VladD2, Вы писали:
B>>С нормальным визуальным редактором, VD>Не нужен никому этот редактор. Нельзя в нем полноценно отобразить MVVM-ые фичи вроде биндинга. Вот превью нужно. Но быстрое, а не те тормоза, что в Студии есть. И качественное. А то у меня редактор XAML постоянно падает.
Помнится когда-то давно мы с тобой спорили на эту тему. Так вот я сейчас посмотрел видео (из первого сообщения) и только ещё больше убедился в своей правоте. Результат, достигаемый этим инструментом в результате активной 25 минутной работы, я легко повторю другим инструментом (с продвинутым визуальным редактором) где-то за минуту ленивого шевеления мышкой.
P.S. Если что, это не претензия к обсуждаемому продукту. Продукт выглядит отлично, насколько это возможно при построение его вокруг такой сомнительной базы (WPF).
Здравствуйте, alex_public, Вы писали:
_>Так вот я сейчас посмотрел видео (из первого сообщения) и только ещё больше убедился в своей правоте. Результат, достигаемый этим инструментом в результате активной 25 минутной работы, я легко повторю другим инструментом (с продвинутым визуальным редактором) где-то за минуту ленивого шевеления мышкой.
О, у меня подобное ощущение возникло — как минимум начальный макет в нормальном визуальном редакторе получился бы быстрее, и из
этого макета можно было бы сгенерировать ту же самую human-friendly декларативную разметку для дальнейших модификаций, а то и вовсе двустороннюю связь.
Здравствуйте, bazis1, Вы писали:
B>P.S. Лучше бы кто-нибудь запилил XAML для сайтостроения. С нормальным визуальным редактором, strong typed binding-ами безо всяких angular-извращений, интеграцией в IDE и нормальной библиотекой контролов типа всяких TreeView. Вот это взлетит в отличие от.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, ionoy, Вы писали:
I>>Циклы в XAML реализуются через ItemsControl и ItemTemplate, так что циклы не нужны.
IT>Сразу чувствуется школа Влада в общении с потенциальными пользователями
IT>Как мне без копипасты определить десять однотипных кнопок?
Написать руками если не хочется Ctrl-C, Ctrl-V использовать
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, okon, Вы писали:
O>>Написать руками если не хочется Ctrl-C, Ctrl-V использовать O>>А как предполагалось бы сделать иначе ?
_AB>Наверное (чисто догадка), что-то типа такого. _AB>
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Ключевое слово set можно будет использовать и здесь.
Я когда начинал делать Ammy тоже везде искал места, где можно заменить кучку кода на микро-DSL. Тоже думал про стили, триггеры, ресурсы, анимации. Но чем дальше, тем больше я верю в то, что если есть возможность решить что-то базовыми средствами языка, то новый синтаксис добавлять не стоит. Да, сейчас миксины и алиасы пока не на том уровне, чтобы быть абсолютно на равне со специализированым синтаксисом, но им ничего не мешает стать таковыми.
Уже сейчас я вижу, что XAML платформ значительно больше, чем я предполагал. Большинство из них следуют основным принципам заложенным ещё при WPF: стили, триггеры, targettype и прочее. Но постепенно появляются отклонения, которые ломают back compatibility. Для того чтобы иметь возможность поддерживать любую XAML платформу надо быть гибким, а это значит по минимум хардкодить разметку с помощью ключевых слов. Те же миксины абсолютно ничего не знают о WPF, UWP и других вещах. Я уверен, что будь желание и можно было бы Ammy прикрутить хоть к HTML. Хочется двигаться в направлении, которое даст наибольшую гибкость, а значит возможность поддерживать любые бэкенды хоть отдалённо напоминающие XAML.
Кстати, одну такую "ошибку" я уже совершил с `bind`, который превращается в `<Binding />`. У UWP, например появился новый механизм биндинга, так что мне придётся выдумывать как их различать. Другое дело что именно биндинг практически нереально упростить используя миксины.
В любом случае, спасибо за предложения. Видно что ты их продумывал, а не просто с бухты барахты фичи реквестируешь.
Собственно ItemsControl это почти то же самое, только нельзя биндить число как количество повторений. Можно от него отнаследоваться и завернуть в alias:
Здравствуйте, ionoy, Вы писали:
I>Для стилей сейчас есть миксин #Setter:
Да я как раз после того как на эти миксыны посмотрел и написал это сообщение.
1)Куча визуального шума.
2)Нет интеллисенса.
I>Правда set был убран, чтобы быстрее зарелизиться. Надо будет добавить его обратно.
Значительно лучше миксинов. Но немного хуже моего варианта.
Ибо очень часто нужно будет присвоить одно или два свойства.
I>Триггеры решаются через алиасы:
Те же проблемы что с миксинами стеттеров.
I>Я когда начинал делать Ammy тоже везде искал места, где можно заменить кучку кода на микро-DSL. Тоже думал про стили, триггеры, ресурсы, анимации. Но чем дальше, тем больше я верю в то, что если есть возможность решить что-то базовыми средствами языка, то новый синтаксис добавлять не стоит. Да, сейчас миксины и алиасы пока не на том уровне, чтобы быть абсолютно на равне со специализированым синтаксисом, но им ничего не мешает стать таковыми.
Мы говорим про язык на основе нитры.
Нитра способна создавать модульные языки.
Что тебе мешает сделать базовый язык и сахар, который можно включать/выключать?
Собственно, это и есть одна из главных причин создания нитры.
I>Для того чтобы иметь возможность поддерживать любую XAML платформу надо быть гибким, а это значит по минимум хардкодить разметку с помощью ключевых слов.
А вот тут у меня прямо противоположное мнение.
Именно наличие специального синтаксиса позволяет произвольно изменять генерируемый код.
Это позволит использовать один код на разных WPF платформах.
Ну а если не получится, то как я уже говорил языки, созданные на нитре модульные.
И ничто не мешает сделать разный сахар для разных платформ.
I>Кстати, одну такую "ошибку" я уже совершил с `bind`, который превращается в `<Binding />`. У UWP, например появился новый механизм биндинга, так что мне придётся выдумывать как их различать. Другое дело что именно биндинг практически нереально упростить используя миксины.
Ключом компилятора.
I>В любом случае, спасибо за предложения. Видно что ты их продумывал, а не просто с бухты барахты фичи реквестируешь.
Я просто изучил столько языков что мне достаточно прочитать документацию чтобы выявить проблемы и показать пути их решения.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VD> Раже авторы Xamarin-а и Avalon заинтересовались. Они просто твоего мнения наверно не успели прочитать.
Я являюсь одним из ключевых разработчиков AvaloniaUI и в некотором роде разделяю мнение вашего оппонента в части неодобрения выпуска этого счастья под закрытой лицензией. К самой технологии интерес у нас есть, да только вот мы как приличные люди всё выпускаем под MIT и не можем сторонние блобы с очень платными лицензиями интегрировать.
Здравствуйте, kekekeks, Вы писали:
K>Я являюсь одним из ключевых разработчиков AvaloniaUI и в некотором роде разделяю мнение вашего оппонента в части неодобрения выпуска этого счастья под закрытой лицензией. К самой технологии интерес у нас есть, да только вот мы как приличные люди всё выпускаем под MIT и не можем сторонние блобы с очень платными лицензиями интегрировать.
Я как бы сам не рад по поводу закрытости. Мне бы тоже было бы приятнее, если бы исходники были открыты.
Но и автора я понимаю. Все же он вложил море времени. Его хочется хоть как-то окупить.
Что касается лицензий, то это как раз вопрос решаемый, я думаю. Тут можно легко договориться с автором.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kekekeks, Вы писали:
K>Я являюсь одним из ключевых разработчиков AvaloniaUI и в некотором роде разделяю мнение вашего оппонента в части неодобрения выпуска этого счастья под закрытой лицензией. К самой технологии интерес у нас есть, да только вот мы как приличные люди всё выпускаем под MIT и не можем сторонние блобы с очень платными лицензиями интегрировать.
Честно говоря, мне надоело бросать проекты незаконченными из-за недостатка времени или мотивации. Поэтому, когда я начинал работу над Ammy, я сразу решил, что это будет моим основным источником дохода, чтобы можно было спокойно работать фулл-тайм и при этом не думать о том как прокормить семью. Последний год я работал в режиме 3 недели на Ammy, 1 неделя на подработки, чтобы заработать прожиточный минимум. Сейчас работаю с утра до вечера почти без выходных, всё для того чтобы максимально быстро исправлять баги и двигать проект вперёд.
По поводу лицензии, то, честно говоря, не вижу большой проблемы. Если ты пишешь что-то чисто для себя, без цели заработка, то пожалуйста, получай все плюшки Ammy забесплатно. Если же ты хочешь свой продукт продавать, то цена Ammy практически не повлияет на общую стоимость разработки. Если учесть налоги, то лицензия Ammy — это около 10% от стоимости одного разработчика, а то и меньше. И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.
Честное слово, я всеми руками за опен сорс. Все мои предыдущие проекты разрабатывались в открытом виде и были доступны всем желающим. Но до тех пор, пока я не буду уверен в стабильном будущем, я не могу открыть код Ammy.
Насчёт интеграции с AvaloniaUI. Совсем необязательно делать Ammy единственным возможным языком разметки, достаточно дать людям возможность подключать её по желанию. Собственно со всеми остальными платформами именно такой вариант и будет иметь место. На днях, например, постучался разработчик на NoesisGUI и мы с ним вдвоём довольно быстро сделали поддержку этого фреймворка. Теперь люди, которые пишут на NoesisGUI, могут подключить нугет пакет и пользоваться Ammy в своих приложениях.
У вас в категории why ammy — написана какая-то хрень неизвестно для кого.
* Free!
* Easy to learn
* XAML compatible
* Syntax meant for people
* Mixins and variables
* Realtime update
* Nuget package
* Visual Studio extension
* Good support
о чем и для кого все это?
какую мысль вы хотели донести?
где value для бизнеса?
детский сад, честное слово
Посмотрите хотя бы на постшарп
* Reduce development costs and deliver faster.
* Build more reliable software.
* Add functionality more easily after the first release.
* Help new team members contribute quicker.
всё бизнес, быстрее, лучше, проще
Здравствуйте, ionoy, Вы писали:
I>Честно говоря, мне надоело бросать проекты незаконченными из-за недостатка времени или мотивации. Поэтому, когда я начинал работу над Ammy, я сразу решил, что это будет моим основным источником дохода, чтобы можно было спокойно работать фулл-тайм и при этом не думать о том как прокормить семью. Последний год я работал в режиме 3 недели на Ammy, 1 неделя на подработки, чтобы заработать прожиточный минимум. Сейчас работаю с утра до вечера почти без выходных, всё для того чтобы максимально быстро исправлять баги и двигать проект вперёд.
Т.е. Вы потратили 9 месяцев фуллтайма на разработку продукта, имеете ноль продаж и вместо того, чтобы с головой погружаться в налаживание и оптимизацию воронки продаж, продолжаете пилить техническую сторону? Пожалуйста, оглянитесь по сторонам и прочитайте что-нибудь вроде классики. ИМХО, Вы наступаете на грабли, стоящие на пути у 100% шароварщиков с программистским прошлым и дальнейший успех вашего продукта практически полностью зависит от того, насколько быстро Вы смените менталитет с программистского на предпринимательский.
Вот у меня второй год подряд чешется шило в заднице сделать web-сервис, в котором можно будет просматривать исходники библиотек, как будто бы в Visual Studio. С go-to-definition, find all references, подсветкой использований переменной, раскрытием макросов, списком полей, function argument hints и переформатированием кода под ваш любимый стиль прямо на ходу. Технологии для этого у меня есть, нужно только месяцев 6 работы. И я второй год бью себя по рукам, ибо понимаю, что при всей крутости идеи, фиг я ее монетизирую, да еще и на хостинг, который потянет наш IntelliSense-движок, вбухаю безвозвратно кучу денег.
I>По поводу лицензии, то, честно говоря, не вижу большой проблемы. Если ты пишешь что-то чисто для себя, без цели заработка, то пожалуйста, получай все плюшки Ammy забесплатно. Если же ты хочешь свой продукт продавать, то цена Ammy практически не повлияет на общую стоимость разработки.
Разработчик-одиночка на стадии выбора инструмента имеет расплывчатую идею и ноль продаж. Не факт, что его шаровара в первый год принесет даже эти несчастные 200 долларов, поэтому уходить в минус ради абстрактного преимущества JSON над XML он не будет. I> Если учесть налоги, то лицензия Ammy — это около 10% от стоимости одного разработчика, а то и меньше. И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.
Во-первых, 299 это чуть меньше, чем 300, а не чуть больше, чем 200. Во-вторых, вы лезете в игру, не понимая ее правил. Люди, которые имеют авторизацию потратить 3.5K в год, мыслят совершенно другими категориями, такими как corporate influence, budget spending, head count и т.п., и ваше сравнение с девелоперской зарплатой будет звучать как в том анекдоте:
- Почем яблоки?
— Штука баксов килограмм.
— А че так дорого?
— Да очень деньги нужны.
I>Честное слово, я всеми руками за опен сорс. Все мои предыдущие проекты разрабатывались в открытом виде и были доступны всем желающим. Но до тех пор, пока я не буду уверен в стабильном будущем, я не могу открыть код Ammy. Пожалуйста, подумайте над моим советом в предыдущем посте. Сделайте плагин для студии, который сделает прозрачный edit-and-continue для обычного XAML. Баксов за 50 (единоразово + год апдейтов) это принесет вам достаточно пользователей при относительно небольших трудозатратах. Я сам буду одним из ваших первых клиентов, ибо тормоза штатного редактора достали и риска при таком раскладе ноль. А вот переписывать код с XAML на JSON я не буду, ибо ИМХО, это шило на мыло. И думаю, со мной согласится еще куча народа, использующего XAML.
Edit: упс, поздно.
B>Т.е. Вы потратили 9 месяцев фуллтайма на разработку продукта, имеете ноль продаж и вместо того, чтобы с головой погружаться в налаживание и оптимизацию воронки продаж, продолжаете пилить техническую сторону? Пожалуйста, оглянитесь по сторонам и прочитайте что-нибудь вроде классики. ИМХО, Вы наступаете на грабли, стоящие на пути у 100% шароварщиков с программистским прошлым и дальнейший успех вашего продукта практически полностью зависит от того, насколько быстро Вы смените менталитет с программистского на предпринимательский.
Техническая сторона в данном случае — это исправление критических багов и расширение рынка. WPF — это малая часть XAML разработки, поэтому я и стараюсь как можно быстрее выйти на другие платформы. Насчёт смены менталитета, я полностью согласен, основной упор надо будет делать на маркетинг. Но продавать забагованный продукт тоже не хочется, поэтому первый месяц после релиза ушёл исключительно на исправление ошибок.
I>>По поводу лицензии, то, честно говоря, не вижу большой проблемы. Если ты пишешь что-то чисто для себя, без цели заработка, то пожалуйста, получай все плюшки Ammy забесплатно. Если же ты хочешь свой продукт продавать, то цена Ammy практически не повлияет на общую стоимость разработки. B>Разработчик-одиночка на стадии выбора инструмента имеет расплывчатую идею и ноль продаж. Не факт, что его шаровара в первый год принесет даже эти несчастные 200 долларов, поэтому уходить в минус ради абстрактного преимущества JSON над XML он не будет.
Я бы с тобой согласился, если бы не "ради абстрактного преимущества JSON над XML".
I>> Если учесть налоги, то лицензия Ammy — это около 10% от стоимости одного разработчика, а то и меньше. И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли. B>Во-первых, 299 это чуть меньше, чем 300, а не чуть больше, чем 200. Во-вторых, вы лезете в игру, не понимая ее правил. Люди, которые имеют авторизацию потратить 3.5K в год, мыслят совершенно другими категориями, такими как corporate influence, budget spending, head count и т.п.
Уже запланирован ещё один пакет для маленьких компаний + bulk скидки.
Понимаю, что вы хотите помочь, но я тоже достаточно долго продумывал организацию всего этого дела. Поэтому хочу попробовать сделать так как считаю нужным. Если из этого ничего не выйдет, то у вас будет возможность сказать "I told you so", а если всё получится то будет хорошо всем, и мне, и Ammy, и проекту Nitra.
>И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.
Маленький ньюанс касательно СНГ и ценовой политики. Xamarin в своё время стоил $25/мес с разработчика за целую платформу. Народ повсеместно пиратил. Я за цельный решарпер со всеми его анализаторами, профайлерами поддержкой в год $90 плачу. И когда предлагаю другим перестать его пиратить (хороший продукт же) на меня народ смотрит странно.
Да и для не-СНГ цены выглядят задраными на фоне тех, что приведены выше. Так что присоединяюсь к мнению остальных ораторов и настоятельно рекомендую найти продажника, который проанализирует рынок.
K>Да и для не-СНГ цены выглядят задраными на фоне тех, что приведены выше. Так что присоединяюсь к мнению остальных ораторов и настоятельно рекомендую найти продажника, который проанализирует рынок.
Если я не ошибаюсь, то у Xamarin'а не было некоммерческой лицензии, так что там в любом случае надо было платить. За решарпер надо было платить разом, достаточно много, и бесплатной лицензии тоже не было.
Но может вы и правы, на данном этапе это цена несколько высоковата. Может региональные скидки добавить? Всё-таки возможности разработчиков СНГ и северной америки значительно отличаются.