roboforum.ru

Вроде Qt Creator хранит формы в XML, но наверное на МК всякие XML - зло?

Заодно получите готовый редактор формы, останется только вывод сделать на девайсе

<PRESS>
IO 8 1
DELAY 2
IO 14 0
DELAY 2
IO 15 1
DELAY 2
IO 15 0
DELAY 2
SER1 BLUEBEE
<END>

Вот это уже совсем не гуй, а скриптовый action-язык какой-то

можно на подобии сделать

Код: Выделить всё • Развернуть

<Window x:Class="OliverCode.MVVM.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="MVVM Demostration" Height="297" Width="480"
    xmlns:views="clr-namespace:OliverCode.MVVM.View">
    
    <Grid Margin="10">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="460*"/>
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="40"/>
            <RowDefinition Height="80*"/>
        </Grid.RowDefinitions>
        <Border CornerRadius="5" BorderBrush="SteelBlue" BorderThickness="2" Grid.Row="0">
            <Label Height="30" Width="400" Content="Below is a two way binding between the view view-model, and model"/>
        </Border>
        <Border CornerRadius="5" BorderBrush="SteelBlue" BorderThickness="2" Grid.Row="1" Margin="0,5,0,0">
            <views:PersonView/>
        </Border>
    </Grid>
</Window>

описание внешнего вида находится между

Код: Выделить всё • Развернуть

<Grid Margin="10"> ...   </Grid>

а это что из себя представляет <views:PersonView/>:

Код: Выделить всё • Развернуть

<UserControl x:Class="OliverCode.MVVM.View.PersonView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Height="Auto" Width="Auto"
    xmlns:local="clr-namespace:OliverCode.MVVM.ViewModel">
    <StackPanel Orientation="Vertical" Margin="4">
        <!--Here is where we the view gets a copy to the ViewModel Declaratively-->
        <StackPanel.DataContext>
            <local:PersonViewModel />
        </StackPanel.DataContext>        
        <StackPanel Orientation="Vertical" DataContext="{Binding Path=Person, Mode=TwoWay}" Margin="4">
            <StackPanel Orientation="Horizontal">
                <Label Content="First Name:" Margin="0,0,4,0"/>
                <TextBox Width="250" Text="{Binding Path=FirstName}"/>
            </StackPanel>
            <StackPanel Orientation="Horizontal" Margin="0,5,0,0">
                <Label Content="Last Name:" Margin="0,0,4,0"/>
                <TextBox Width="250" Text="{Binding Path=LastName}"/>
            </StackPanel>
            <StackPanel Orientation="Horizontal" Margin="0,5,0,0">
                <Label Content="Age:" Margin="35,0,4,0"/>
                <TextBox Width="50" MaxLength="3" Text="{Binding Path=Age}"/>
            </StackPanel>
        </StackPanel>        
        <StackPanel>
            <Button Content="Save" HorizontalAlignment="Right" Width="80" Command="{Binding Path=SavePersonCommand}"/>
        </StackPanel>
    </StackPanel>
</UserControl>

можно и динамически подгружаемым/изменяемым сделать. вопрос в том, есть ли желание делать что-то подобное.

Глянь QML, под него парсер будет простым (это просто JSON), хипы с маллоками по желанию.

Не, ну за пару-то месяцев можно и не такое написать, кто же спорит...
Мне же чисто в утилитарных целях, а не в целях "совершенствования всего и вся" )

Ну я на него посматриваю, только парсер все-равно писать, и смысл придерживаться какому-то внешнему стандарту теряется.

Добавлено спустя 8 минут 14 секунд:

Глянь QML, под него парсер будет простым...

Тогда уж проще YAML - я уже выше предлагал его...

Ребят, если я не отвечаю, это не значит, что игнорирую - я честно смотрю, читаю, мотаю на ус...

Просто я думаю, что в "универсальном" парсере необходимости нет вовсе.
Нафиг мне такой уровень абстракции (и абстрагирования от задачи)?
Скорее всего это будут все-таки предопределенные ключевые слова.
А синтаксис, да, нравится.

Продолжу. (Какое-то время проект был в подвешенном состоянии)

Пока видится два диаметрально противоположных подхода:
1. Более-менее полноценный язык программирования. То есть с карточки подгружается скрипт, который выполняется, рисует все что надо, где надо и вызывает нэйтив-функции, которые отвечают, собственно, за функционал.
Плюсы-минусы:
+ Абсолютная гибкость. Можно кардинально перелопатить и интерфейс и логику его работы.
+ Простая реализация API (нэйтив-функций) со стороны встроенного ПО.
- Сложность реализации интерпретатора (компилятора в байт-код, JIT-компилятора).
- GUI не отделен от программирования, хотя и отделен от основного функционала.
Примеры - экшнскрипт, вижуалбэйсик...

2. Чистый язык описания интерфейса. Все функции делает встроенное ПО, которое загружает с карточки только параметры предопределенных объектов.
Плюсы минусы.
+ дизайн абсолютно отделен от программирования
+ простой парсер без наворотов
* встроенное ПО объемное, но в меру сложное
- Логика работы интерфейса жестко задана
Примеры - скины, файлы ресурсов

Можно предложить разные "промежуточные" варианты. Например:
3. Функционирование устройства определяется структурой данных, которую предоставляет пользовательский интерфейс.
Плюсы-минусы:
+ Гибкое решение. Можно кардинально перелопатить и интерфейс и логику его работы.
+ Дизайн отделен от программирования, но его описание довольно сложное.
* Умеренно сложный интерпретатор скрипта
- Сложная организация встроенного ПО, перегруженный API к интерфейсу
- Необходимость "специальных" элементов интерфейса или функций для реализации функционала.

Еще варианты? Мысли?