Comments 64
Какая ужасная презентация, обрубок пальца оставил не совсем приятные впечатления, лучше бы обычной стрелочкой обошлись. Сказывается тренд Тач Скринов.
О, Боже, отрубленный палец!
не обижайтесь… но вообще не впечатляет.
что собственно нового в том, что вы показали?
Rectangle
{
width = 200
}
и кого это должно было восхитить? тут есть что-то чего ещё не было?
из поста вообще не видно причём тут css и как это позволяет разделить работу дизайнера и программиста.
не хочется преждевременно плеваться на чей-то труд… но пост просто убогий… честно…
что собственно нового в том, что вы показали?
Rectangle
{
width = 200
}
и кого это должно было восхитить? тут есть что-то чего ещё не было?
из поста вообще не видно причём тут css и как это позволяет разделить работу дизайнера и программиста.
не хочется преждевременно плеваться на чей-то труд… но пост просто убогий… честно…
Видио можно было и под кат засунуть.
Вы про WPF слышали? Презентации/примеры видели? Вполне себе такой декларативный подход, причем неплохо реализованный. Так что нового ничего нет, просто еще один вариант реализации.
Про WPF слышал, но насколько я знаю он базируется на xml'е, а QML на json, да и существование 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 код :) ну суть была в том, что они почти идентичны
Отличие в том, что json более человекопонятный сравните то, что я привел, с
json, банально, читать проще. А здесь немного другая идеология, чтобы её понять, нужно немножко Qt знать. Вы про сигналы/слоты слышали, а про state machine? Далее, QML тесно интегрирован с javascriptом. Можно вот такие штуки делать
В принципе сделать также, как в wpf, не составит труда.
Вообще пока ещё нету полной документации по технологии, релиз видимо лишь в следующем году состоится, да и я всё же не представитель Qt Software.
<Window x:Class="WpfApplication1.Window5"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Тестовый пример" SizeToContent="WidthAndHeight">
<StackPanel>
<Button Click="Button_Click" Margin="5">Нажми меня</Button>
<Button x:Name="btnTest" Margin="5" Padding="5">Тестовая кнопка</Button>
<Button Margin="5" Padding="5">
<StackPanel Orientation="Horizontal">
<TextBlock VerticalAlignment="Center">Кнопка</TextBlock>
<Image Source="Bitmap1.bmp" Margin="5" />
<TextBlock VerticalAlignment="Bottom">с картинкой</TextBlock>
</StackPanel>
</Button>
</StackPanel>
</Window>
* This source code was highlighted with Source Code Highlighter.json, банально, читать проще. А здесь немного другая идеология, чтобы её понять, нужно немножко Qt знать. Вы про сигналы/слоты слышали, а про state machine? Далее, QML тесно интегрирован с javascriptом. Можно вот такие штуки делать
script {
function photoClicked() {
imageDetails.photoTitle = title;
imageDetails.photoTags = tags;
imageDetails.photoWidth = photoWidth;
imageDetails.photoHeight = photoHeight;
imageDetails.photoType = photoType;
imageDetails.photoAuthor = photoAuthor;
imageDetails.photoDate = photoDate;
imageDetails.photoUrl = url;
imageDetails.rating = 0;
scaleMe.state = "Details";
}
}
В принципе сделать также, как в wpf, не составит труда.
Вообще пока ещё нету полной документации по технологии, релиз видимо лишь в следующем году состоится, да и я всё же не представитель Qt Software.
лично мне xml читать как-то сподручнее чем json…
хотя… если вам угодно:
это тот же wpf, только не на xaml, а на C#
можно и так и так писать…
а как у вас с биндингом (или как он у вас называется)?
хотя… если вам угодно:
new Grid()
{
    Width = 100,
    Height = 200,
    Children =
    {
        new TextBox() { Text = "some text" },
        new Button() { Content = "Button1" }
    }
};
это тот же wpf, только не на xaml, а на C#
можно и так и так писать…
а как у вас с биндингом (или как он у вас называется)?
Ну вопрос привычке, я привык к сишному синтаксису, а json больше на него похож. Кто вырос на html'е наверное имеет другое мнение.
В смысле биндингом? Я в .NET'е плохо ориентируюсь. Qt это фреймворк, написанный на C++, но с использованием метаданных, которые в том числе позволяют реализовывать лёгкую привязку к javscriptу, грубо говоря можно обычные Qtшные обьекты (унаследованные от QObject) делать доступными для скриптов. Здесь тот же самый механизм применён.
Вообще вам помоему сюда
В смысле биндингом? Я в .NET'е плохо ориентируюсь. Qt это фреймворк, написанный на C++, но с использованием метаданных, которые в том числе позволяют реализовывать лёгкую привязку к javscriptу, грубо говоря можно обычные Qtшные обьекты (унаследованные от QObject) делать доступными для скриптов. Здесь тот же самый механизм применён.
Вообще вам помоему сюда
упростим вопрос:
у вас есть какой-то input. как введённое значение присвоить какому-то свойству объекта?
у вас есть какой-то input. как введённое значение присвоить какому-то свойству объекта?
Конечно есть, советую взглянуть на демки, например, на web browser
лежит в demos/declarative/webbrowser
лежит в demos/declarative/webbrowser
Чтобы не ставить себе весь пакет, может быть вкратце изложите суть? А то терзают смутные сомнения насчет привязок — например, как они задаются в этой json-разметке и как работают.
А, сорри, я был невнимателен:
Однако, есть подозрение, что работать это будет только для визуальных элементов, которые должны иметь имя. Привязаться таким образом к полям произвольного объекта нельзя. Верно?
value: slider.x *100 / (container.width - 34)
Однако, есть подозрение, что работать это будет только для визуальных элементов, которые должны иметь имя. Привязаться таким образом к полям произвольного объекта нельзя. Верно?
pastebin.ca/1672687
Вот тут пример. Из кода всё очевидно
Когда мы кликаем в определенное место на форме, которое помечено якорем (в данном случае якорь указывает на иконку confirm), или просто генерируем событие Accepted, вызывается javascript функция confirm(), которая считывает данные из input'а, присваивает их объекту, а потом отсылает сигнал confirmed, который ловится браузером
Вот тут пример. Из кода всё очевидно
MouseRegion {
anchors.fill: confirmIcon
onClicked: { confirm() }
}
TextInput {
id: textEdit
text: fieldText.text
focus: false
anchors.left: parent.left
anchors.leftMargin: 0
anchors.right: parent.right
anchors.rightMargin: 0
anchors.verticalCenter: parent.verticalCenter
color: "black"
font.bold: true
readOnly: true
onAccepted: confirm()
Keys.onEscapePressed: reset()
}
Когда мы кликаем в определенное место на форме, которое помечено якорем (в данном случае якорь указывает на иконку confirm), или просто генерируем событие Accepted, вызывается javascript функция confirm(), которая считывает данные из input'а, присваивает их объекту, а потом отсылает сигнал confirmed, который ловится браузером
Не, это не интересно — это обычная обработка событий.
Биндинг — это когда при изменении свойства какого-либо объекта автоматически меняются зависящие от него свойства других объектов. Например, когда меняется значение в текстовом поле, то автоматически меняется и значение в соответствующей записи в таблице данных, и наоборот.
Биндинг — это когда при изменении свойства какого-либо объекта автоматически меняются зависящие от него свойства других объектов. Например, когда меняется значение в текстовом поле, то автоматически меняется и значение в соответствующей записи в таблице данных, и наоборот.
А что мешает это через сигналы/слоты сделать? (кстати в WPF есть аналоги для сигналов/слотов или их более мощного варианта — state машины?)
Вообще это ещё далеко не релиз, а статья больше ориентирована на Qt разрабов, чтобы они как-то обратили внимание на то, что их ждёт в будущем и начали хоть как-то готовить свои графические приложения к использованию этой технологии.
Вообще это ещё далеко не релиз, а статья больше ориентирована на Qt разрабов, чтобы они как-то обратили внимание на то, что их ждёт в будущем и начали хоть как-то готовить свои графические приложения к использованию этой технологии.
Мешает то, что это нужно делать. А потом — поддерживать. И при изменении в 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 — вернее, они априори не были мелкими :)
sauron@northrend ~/Develop/qutim/sdk03 $ cat 3rdparty/k8json/k8json.cpp | wc -l
788
Это разве много? Парсит в QVariant. И что разве размер QtGui как то влияет на размер исполняемых файлов? Qt как бы оптимизируют под embedded устройства поэтому с производительностью там всё хорошо
788
Это разве много? Парсит в QVariant. И что разве размер QtGui как то влияет на размер исполняемых файлов? Qt как бы оптимизируют под embedded устройства поэтому с производительностью там всё хорошо
Размер QtGui влияет на размер дистрибутива.
В Линуксе её вообще лишь один раз придется поставить, пользователи Windows'а обычно редко жалуются, они и без этого привыкли к весьма пухленьким дистрам, это может быть критично лишь на embedded устройствах, но в Qt есть опции сборки, позволяющие для таких устройств выкидывать ненужные части.
Сейчас дистрибутивы куда больше разъедаются на всякой графической и мультимедийной информации.
Сейчас дистрибутивы куда больше разъедаются на всякой графической и мультимедийной информации.
Мелкие утилитки несовместимы с графическими интерфейсами.
А для графических морд к мелким утилиткам пока ничего лучше Tcl/Tk не придумали.
А для графических морд к мелким утилиткам пока ничего лучше Tcl/Tk не придумали.
Не дайте Астронавтам Архитектуры вас запугать
Sign up to leave a comment.
QML — новый подход к построению GUI