Comments 64
Какая ужасная презентация, обрубок пальца оставил не совсем приятные впечатления, лучше бы обычной стрелочкой обошлись. Сказывается тренд Тач Скринов.
О, Боже, отрубленный палец!
не обижайтесь… но вообще не впечатляет.
что собственно нового в том, что вы показали?
Rectangle
{
width = 200
}
и кого это должно было восхитить? тут есть что-то чего ещё не было?
из поста вообще не видно причём тут css и как это позволяет разделить работу дизайнера и программиста.
не хочется преждевременно плеваться на чей-то труд… но пост просто убогий… честно…
что собственно нового в том, что вы показали?
Rectangle
{
width = 200
}
и кого это должно было восхитить? тут есть что-то чего ещё не было?
из поста вообще не видно причём тут css и как это позволяет разделить работу дизайнера и программиста.
не хочется преждевременно плеваться на чей-то труд… но пост просто убогий… честно…
Видио можно было и под кат засунуть.
Вы про WPF слышали? Презентации/примеры видели? Вполне себе такой декларативный подход, причем неплохо реализованный. Так что нового ничего нет, просто еще один вариант реализации.
а между xaml и json есть какие-то принципиально отличие?
object { items: [subobject {name: «value»}] }
как-то раз я даже писал конверт из xml в json и обратно. если придерживаться некоторых правил, то можно даже добиться взаимооднозначного соответствия.
xaml в конечном счёте всё равно превращается в код, предполагаю, что QML тоже.
а как у вас дела обстоят с разделением программист/дизайнер?
к примеру в wpf широко используются DataTemplate. вы скармливаете контролу любой объект, и в зависимости от выбранного DataTemplate меняется его отображения.
как я понял, у вас тоже есть нечто подобное… но в посте я этого не нашёл, как впрочем и на сайте.
хотелось бы узнать поподробнее…
object { items: [subobject {name: «value»}] }
как-то раз я даже писал конверт из xml в json и обратно. если придерживаться некоторых правил, то можно даже добиться взаимооднозначного соответствия.
xaml в конечном счёте всё равно превращается в код, предполагаю, что QML тоже.
а как у вас дела обстоят с разделением программист/дизайнер?
к примеру в wpf широко используются DataTemplate. вы скармливаете контролу любой объект, и в зависимости от выбранного DataTemplate меняется его отображения.
как я понял, у вас тоже есть нечто подобное… но в посте я этого не нашёл, как впрочем и на сайте.
хотелось бы узнать поподробнее…
сорри… съелся xml код :) ну суть была в том, что они почти идентичны
лично мне xml читать как-то сподручнее чем json…
хотя… если вам угодно:
это тот же wpf, только не на xaml, а на C#
можно и так и так писать…
а как у вас с биндингом (или как он у вас называется)?
хотя… если вам угодно:
new Grid()
{
Width = 100,
Height = 200,
Children =
{
new TextBox() { Text = "some text" },
new Button() { Content = "Button1" }
}
};
это тот же wpf, только не на xaml, а на C#
можно и так и так писать…
а как у вас с биндингом (или как он у вас называется)?
упростим вопрос:
у вас есть какой-то input. как введённое значение присвоить какому-то свойству объекта?
у вас есть какой-то input. как введённое значение присвоить какому-то свойству объекта?
Чтобы не ставить себе весь пакет, может быть вкратце изложите суть? А то терзают смутные сомнения насчет привязок — например, как они задаются в этой json-разметке и как работают.
А, сорри, я был невнимателен:
Однако, есть подозрение, что работать это будет только для визуальных элементов, которые должны иметь имя. Привязаться таким образом к полям произвольного объекта нельзя. Верно?
value: slider.x *100 / (container.width - 34)
Однако, есть подозрение, что работать это будет только для визуальных элементов, которые должны иметь имя. Привязаться таким образом к полям произвольного объекта нельзя. Верно?
Не, это не интересно — это обычная обработка событий.
Биндинг — это когда при изменении свойства какого-либо объекта автоматически меняются зависящие от него свойства других объектов. Например, когда меняется значение в текстовом поле, то автоматически меняется и значение в соответствующей записи в таблице данных, и наоборот.
Биндинг — это когда при изменении свойства какого-либо объекта автоматически меняются зависящие от него свойства других объектов. Например, когда меняется значение в текстовом поле, то автоматически меняется и значение в соответствующей записи в таблице данных, и наоборот.
Мешает то, что это нужно делать. А потом — поддерживать. И при изменении в UI или в логике переделывать обработчики событий.
WPF — это Presentation, стейт-машинам в нем делать нечего. Для них есть Workflow Foundation.
А сигналы/слоты — это обычные события и их обработчики в терминологии .NET. Они есть независимо от WPF — хоть в WinForms, хоть вообще без всякого GUI.
WPF — это Presentation, стейт-машинам в нем делать нечего. Для них есть Workflow Foundation.
А сигналы/слоты — это обычные события и их обработчики в терминологии .NET. Они есть независимо от WPF — хоть в WinForms, хоть вообще без всякого GUI.
State Machine — есть.
DataBinding там отличный (как вам, например Text="{Binding Company.Boss.Name, Mode=TwoWay}). При изменении текста — изменяется свойство Name, в свойстве Boss в свойстве Company объекта из текущего контекста.
XML выглядит понятнее.
Всякая декларативная логика, а у же тем более привязка к событиям элементов управления на форме — элементарно.
DataBinding там отличный (как вам, например Text="{Binding Company.Boss.Name, Mode=TwoWay}). При изменении текста — изменяется свойство Name, в свойстве Boss в свойстве Company объекта из текущего контекста.
XML выглядит понятнее.
Всякая декларативная логика, а у же тем более привязка к событиям элементов управления на форме — элементарно.
есть Visual State Manager, позволяющий определить состояния объектов и способы переходов между ними
дык это все реализуется спокойно механизмом сигнал-слотов.
при изменении например значения в текстовом поле генерируется сигнал changed() (точно названия не помню но идея думаю ясна...). его можно например связать со слотом update() у таблицы и таким образом при изменении данных в поле ввода будут меняться данные в таблице…
при изменении например значения в текстовом поле генерируется сигнал changed() (точно названия не помню но идея думаю ясна...). его можно например связать со слотом update() у таблицы и таким образом при изменении данных в поле ввода будут меняться данные в таблице…
не успел((
А changed() у таблицы — со слотом update() у поля? А не зациклит?
не зациклит.
Ок, а как выглядит слот update() у таблицы? Мы сами его пишем, или стандартный?
Если стандартный, то он учитывает, что значение поля может отображаться в нескольких визуальных полях и что нужно обновить остальные, кроме пославшего changed?
И раз это слот таблицы, то он что, опрашивает изменения для всех записей? Не приведет ли это к потере производительности?
И как в этом сценарии добавляется, например, валидация ввода? Или преобразование форматов/типов?
Не холивара ради, мне просто любопытно :)
Если стандартный, то он учитывает, что значение поля может отображаться в нескольких визуальных полях и что нужно обновить остальные, кроме пославшего changed?
И раз это слот таблицы, то он что, опрашивает изменения для всех записей? Не приведет ли это к потере производительности?
И как в этом сценарии добавляется, например, валидация ввода? Или преобразование форматов/типов?
Не холивара ради, мне просто любопытно :)
Ок, на слот update() таблицы приходит сигнал. Это означает, что таблица поменялась. Соответственно, ей нужно со всех связанных визуальных элементов собрать данные. Даже если она знает, от какого визуального элемента пришел сигнал, то все равно нужно реализовывать логику переноса значения из этого элемента в соответствующее поле той записи, которая в настоящий момент ассоциирована с текстовым полем.
Пример посмотрел. Из чего-то, напоминающего биндинг, там только
Пример посмотрел. Из чего-то, напоминающего биндинг, там только
color: fieldText.state == "editing" ? "#505050" : "#AAAAAA", остальное же — обычный код обработки событий, причем, как я понимаю, соответствие там одностороннее, в обратную сторону такая штука работать не будет.
скорее XAML, а не WPF, ибо для WPF возможен и «императивный» подход — описание кодом, а не разметкой. да, я зануда)
по сути согласен, что «всё это уже было», да и принципиальной разницы между xml и json нет
по сути согласен, что «всё это уже было», да и принципиальной разницы между xml и json нет
Опять этот страшный палец
Ух ты, JavaFX :)
java.sun.com/javafx/1/tutorials/ui/syntax/
java.sun.com/javafx/1/tutorials/ui/syntax/
это JavaFX
Ладно, давайте тогда сойдёмся во мнении, что в C++, по-моему такого решения ещё не было. Да и вообще, в очередной раз понимаю, что Тролли (не Хабравские, а из бывшего Trolltech) — молодцы, стараются всеми силами сделать C++ ещё более могучим и самое главное, близким и понятным для разработчиков.
Спасибо.
Спасибо.
Это не новый подход. Авторы явно вдохновились конфигами Hybrid для D: hybrid.team0xf.com/wiki/Main/ConfigFiles
какой-то страшный JSON
Как понимаю, модуль QtGui в новой версии Qt увеличится в объеме раза в два. Мелкие утилитки и Qt станут совсем несовместимыми понятиями.
Не думаю, что парсер json сильно утяжелил библиотеку. Что касается размера, то мелкие утилиты и ранее были не особо совместимы с Qt — вернее, они априори не были мелкими :)
Мелкие утилитки несовместимы с графическими интерфейсами.
А для графических морд к мелким утилиткам пока ничего лучше Tcl/Tk не придумали.
А для графических морд к мелким утилиткам пока ничего лучше Tcl/Tk не придумали.
Не дайте Астронавтам Архитектуры вас запугать
Sign up to leave a comment.
QML — новый подход к построению GUI