GUI control with echo and cat
Or independent guided GUI forms.
One day, I became interested in the question of how to create a user interface of programs and got acquainted with Qt Designer , a utility for developing graphical interfaces that is included in the standard Qt composition.
Among other things, Qt Designer impressed with its ability to save all forms in XML files, which can already be connected directly into the program.
It seemed to me very convenient, since I could draw molds with buttons without departing from the text editor.
And then the idea was not to stop: if the entire interface is described in a third-party file, then the program code may not contain elements of working directly with the forms at all, but only use some kind of program interface that tightly isolates business logic and presentation.
If so, then such a program with a user interface can be written not only in C ++, oh, the sacred GNU, it can even be possible without a programming language.
')
Not yet released, it was urgent to invent how this can be cranked.
And so the concept of OpenForm came into being - creating and managing forms using the command line.
Where the basic idea is based on the fact that any state of the interface can be represented in XML format.
So if I want to draw a form, I just need some kind of utility that will take on the task of displaying the forms directly, and all the logic will be on the side.
In other words, such a mini Qt Designer is required, which will read the description of forms and widgets, and this matter will already be displayed. And in order to change the state of the interface, you just need to somehow convey a new description to the program, for example, in the form of XML.
So it turns out that OpenForm first reads the form description file, draws them, and hangs certain triggers, that is, actions, on the specified events.
If an event happens, for example someone clicked somewhere, then some action is performed. And the action is nothing more than the execution of some external program, which should return the new state of the user interface.
And now the points.
1. Qt Designer saves the design as an * .ui XML file.
2. OpenForm reads these files and displays.
3. Triggers are hung on certain events.
4. If an event occurs, a third-party command or program is executed that should return the new state of the interface, that is, output the XML of the new design version to the standard output device.
OpenForm works with * .ui files that are created in the Qt Designer environment.
And besides the default ability to just display the form, it also has additional buns.
For those who do, comments are very necessary, if not to say necessary.
A complete set for those who do not let go: the familiar directive for the preprocessor #include.
Now you can divide the interface into modules.
By tradition, if * .ui executable files, the header should be as * .hui
file: geometry.hui:
file: widget.ui:
The most important thing for which we all gathered here: the ability to monitor the state of the user interface using a third-party program via the command line.
This means that if the user clicks on the button named btnSubmit , the command will be executed
cat update_widget.uui , which displays the contents of the file with the new interface state.
action = return is needed when you want to ask something from the user or find out the state of the interface from an external program that calls OpenForm ( see the example with the dialog box ).
OpenForm has another extraordinary ability to get the value of widget properties. Those. if you need to know what the user typed in the input field, you can use the construction {WIDGET_NAME.PROPERTY_NAME}
for example
Where {lineEdit.text} - this means that from the lineEdit widget to return the value of the property named text . If the user enters something, it can be transferred to a third-party script.
The same works for boolean properties.
Returns true or false.
If you need to use {in commands, then you can just write like this \ {
If the trigger returns a design in the form
then the form is redrawn.
But in cases when you do not need to re-recreate the form, and you just need to update the state of one element, you can use:
This is how we approached the question of how this way you can manage the graphical interface using the echo utility.
Often you do not want to create new design files for each event, so you can immediately indicate in the triggers what needs to be changed and how.
On the click event, the echo command will be executed, where [[ will be replaced by < , and ]] - by > . The result will be copying text from the lineEdit input field to the label object.
Well, for example, an assistant when installing software:
Figure 1. Step license agreement.
Figure 2. Example of animation, progress bar.
You can even just ask about something terrible user with the help of graphic forms.
Figure 3. Dialog box waiting for action from the user.
Works as follows:
Well, or ... or maybe write a graphing calculator on the bash.
Figure 4. Graphing calculator with processing expressions on the bash.
Or even like this:
Figure 5. PHP graphing calculator.
Prehistory
One day, I became interested in the question of how to create a user interface of programs and got acquainted with Qt Designer , a utility for developing graphical interfaces that is included in the standard Qt composition.
Among other things, Qt Designer impressed with its ability to save all forms in XML files, which can already be connected directly into the program.
It seemed to me very convenient, since I could draw molds with buttons without departing from the text editor.
And then the idea was not to stop: if the entire interface is described in a third-party file, then the program code may not contain elements of working directly with the forms at all, but only use some kind of program interface that tightly isolates business logic and presentation.
If so, then such a program with a user interface can be written not only in C ++, oh, the sacred GNU, it can even be possible without a programming language.
')
Not yet released, it was urgent to invent how this can be cranked.
Openform
And so the concept of OpenForm came into being - creating and managing forms using the command line.
Where the basic idea is based on the fact that any state of the interface can be represented in XML format.
So if I want to draw a form, I just need some kind of utility that will take on the task of displaying the forms directly, and all the logic will be on the side.
In other words, such a mini Qt Designer is required, which will read the description of forms and widgets, and this matter will already be displayed. And in order to change the state of the interface, you just need to somehow convey a new description to the program, for example, in the form of XML.
So it turns out that OpenForm first reads the form description file, draws them, and hangs certain triggers, that is, actions, on the specified events.
If an event happens, for example someone clicked somewhere, then some action is performed. And the action is nothing more than the execution of some external program, which should return the new state of the user interface.
And now the points.
1. Qt Designer saves the design as an * .ui XML file.
2. OpenForm reads these files and displays.
3. Triggers are hung on certain events.
4. If an event occurs, a third-party command or program is executed that should return the new state of the interface, that is, output the XML of the new design version to the standard output device.
Manual
OpenForm works with * .ui files that are created in the Qt Designer environment.
<ui version="4.0" > <class>MainWindow</class> <widget class="QMainWindow" name="MainWindow"> <property name="windowTitle"> <string>MainWindow</string> </property> </widget> </ui> And besides the default ability to just display the form, it also has additional buns.
Lattice comment
For those who do, comments are very necessary, if not to say necessary.
<ui version="4.0" > <class>MainWindow</class> <widget class="QMainWindow" name="MainWindow"> # This is a comment <property name="windowTitle"> <string>MainWindow</string> # title of window # <string>MainWindow changed</string> # unneeded title </property> </widget> </ui> Divide and connect
A complete set for those who do not let go: the familiar directive for the preprocessor #include.
Now you can divide the interface into modules.
By tradition, if * .ui executable files, the header should be as * .hui
file: geometry.hui:
<property name="geometry" > <rect> <x>0</x> <y>0</y> <width>800</width> <height>600</height> </rect> </property> file: widget.ui:
<ui version="4.0" > <class>MainWindow</class> <widget class="QMainWindow" name="MainWindow"> <property name="windowTitle"> <string>MainWindow</string> </property> #include "geometry.hui" </widget> </ui> Events, signals and triggers
The most important thing for which we all gathered here: the ability to monitor the state of the user interface using a third-party program via the command line.
<triggers> <trigger object="btnSubmit"> <event signal="clicked">cat update_widget.uui</event> </trigger> </triggers> This means that if the user clicks on the button named btnSubmit , the command will be executed
cat update_widget.uui , which displays the contents of the file with the new interface state.
<triggers> # OBJECT_NAME <trigger object="OBJECT_NAME"> # . # signal: Qt # action: # "execute" - COMMAND , XML # "return" - COMMAND <event signal="SIGNAL" action="execute|return">COMMAND</event> </trigger> </triggers> action = return is needed when you want to ask something from the user or find out the state of the interface from an external program that calls OpenForm ( see the example with the dialog box ).
Take and process
OpenForm has another extraordinary ability to get the value of widget properties. Those. if you need to know what the user typed in the input field, you can use the construction {WIDGET_NAME.PROPERTY_NAME}
for example
<event signal="clicked">php script.php —user-input={lineEdit.text}</event> Where {lineEdit.text} - this means that from the lineEdit widget to return the value of the property named text . If the user enters something, it can be transferred to a third-party script.
The same works for boolean properties.
<event signal="clicked">php script.php --checked={checkBox.checked}</event> Returns true or false.
Screening
If you need to use {in commands, then you can just write like this \ {
Spot update
If the trigger returns a design in the form
<ui version="4.0"> ... </ui> then the form is redrawn.
But in cases when you do not need to re-recreate the form, and you just need to update the state of one element, you can use:
<update> ... </update> Finally, GUI control with echo
This is how we approached the question of how this way you can manage the graphical interface using the echo utility.
Often you do not want to create new design files for each event, so you can immediately indicate in the triggers what needs to be changed and how.
<event signal="clicked">echo "[[update]] [[widget name='label']] [[property name='text']] [[string]]{lineEdit.text}[[/string]] [[/property]] [[/widget]] [[/update]]" </event> On the click event, the echo command will be executed, where [[ will be replaced by < , and ]] - by > . The result will be copying text from the lineEdit input field to the label object.
Well, why is all this necessary?
Well, for example, an assistant when installing software:
Figure 1. Step license agreement.
Figure 2. Example of animation, progress bar.
You can even just ask about something terrible user with the help of graphic forms.
Figure 3. Dialog box waiting for action from the user.
Works as follows:
#!/bin/bash an=`./dialog.ui` if [ $an = 'yes' ]; then echo 'There should be real installation of something very cool' else echo 'Ok, we will do nothing...' fi Well, or ... or maybe write a graphing calculator on the bash.
Figure 4. Graphing calculator with processing expressions on the bash.
Or even like this:
Figure 5. PHP graphing calculator.
Source: https://habr.com/ru/post/212013/
All Articles