Revision [32811]

This is an old revision of gtkdialogDocTips3 made by zigbert on 2020-07-21 03:25:18.

 

HomePage > SoftwareIndex Software Index > SoftwareDevelopment Development > gtkdialog gtkdialog

GtkDialog Tips and Tricks


GtkDialog lets your bash script run in gui.
Here's some tips for learning more about gtkdialog.

This info is based on input from many people. Please share your knowledge.


INDEX

1. Where to start - links to documentation and examples.
2. Syntax - How to use variables in the code.
3. Let the script return data - Choose a proper coding structure.
4. Let external code act on your gtkdialog gui
5. The benefits of a config file
6. Speed issues - Let your turtle run
7. Extended use of widgets - Undocumented features
8. Advanced Syntax - make your code readable
9. Text managing
10. Tips and tricks

Tips and tricks - Links



1.

Where to start

Most importantly, Thunor has written a comprehensive reference guide for all the gtkdialog widgets. This is the place to go for knowledge about syntax and options.

In addition there are other resources which may give some more flesh to the bone.
⚫ Basic tutorials here and here
⚫ Examples are often easier to understand.
⚫ General documentation of gtkdialog is poor, but it's a start.
⚫ The command 'gtkdialog --help' shows available parameters.

⚫ Get the gtkdialog code



2.

Syntax

https://web.archive.org/web/20200524085209/ The basics of building a simple gui is told by the links in chapter 1. You should have played a little bit before you continue.

About QUOTES ( " and ' )
To show content of a variable in the gtkdialog code, we need to quote the variable correctly inside the gtkdialog code.

TEXT='Hello world'

export script='
<text>
 <label>Content of variable is: '"$TEXT"'</label>
</text>'

gtkdialog --program=script


Now in other words - Because this is important!!!

First realize that you put all the gtkdialog code into a variable - ie MAIN_WINDOW or Psync:
export Psync="<window title=\"Psync\"...........</window>"
if you now try to echo Psync you'll get
<window title="Psync"...........</window>
which is correct code. But if you used ' instead of ", like this:
export Psync='<window title=\"Psync\"...........</window>'
you'll get
<window title=\"Psync\"...........</window>
This will give a syntax error, while
export Psync='<window title="Psync"...........</window>'
will give correct syntax.


Now using a variable inside the gtkdialog code like this:
TITLE=Psync
export Psync="<window title=\"$TITLE\"...........</window>"
returns
<window title="Psync"...........</window>
while
export Psync='<window title="$TITLE"...........</window>'
returns
<window title="$TITLE"...........</window>
and not the content of variable TITLE


Now return to the first example about quotes. This example combines the use of ' and ".



3.

Let the script return data

The first step is to show a dialog window on your screen, then the next step is the interaction of the user with the gui. I think the easiest way is to divide guis into different groups. - Simple, Complex and Projects.


Simple
A simple dialog allows the user to give a response to a question/query on the screen:

When the user click on the yes/no/cancel/ok-button the dialog exits and the script continues to evaluate the user input.
Here is an example:
export script='
<vbox>
 <text><label>Are you sure?</label></text>
 <hbox>
  <button no></button>
  <button yes><action>EXIT:sure</action></button>
 </hbox>
</vbox>'

I=$IFS; IFS=""
for STATEMENTS in $(gtkdialog --program=script); do
  eval $STATEMENTS
done
IFS=$I

[ $EXIT = sure ] && gxmessage 'You are sure'


Complex
For more complex dialogs, we want to keep the gui alive even if the user clicks on something, so using an EXIT value is not the right choice. Calling pre-defined functions from inside the gtkdialog gui is a handy way to do this. We must remember to export all functions before executing our gui.
now () {
  date > /tmp/date
}
export -f now

export script='
<vbox>
 <entry>
  <variable>ENTRY_DATE</variable>
  <input>cat /tmp/date</input>
 </entry>
 <button>
  <label>Refresh</label>
  <action>now</action>
  <action>refresh:ENTRY_DATE</action>
 </button>
</vbox>'

gtkdialog -p script


Project
When your project grows and its complexity makes it hard to work with, it's time to consider another approach. Splitting code into several files might be much more usable when working with your code. Group familiar functions into one file... In this example, the function-file must be saved in /root/test to work. Instead of sending <action> to an EXIT-variable, we send it to the file with the function 'now'.

NOTE, that I don't use an ordinary function (like the previous example), but a case command instead. The benefits are faster loading of your app since it does not read your functions into memory, but the greatest advantage is that you can edit the function while the gui is running. The downside are slower execution of the function.

Function file
case $1 in
-now)
  date > /tmp/date
  exit;;
esac

Main file
export script='
<vbox>
 <entry>
  <variable>ENTRY_DATE</variable>
  <input>cat /tmp/date</input>
 </entry>
 <button>
  <label>Refresh</label>
  <action>/root/test -now</action>
  <action>refresh:ENTRY_DATE</action>
 </button>
</vbox>'

I=$IFS; IFS=""
for STATEMENTS in $(gtkdialog -p script); do
  eval $STATEMENTS
done
IFS=$I




4.

Let external code act on your gtkdialog gui


If you want a second gtkdialog-gui to act on your main gui. You simply "launch" the second gui from the main gui. The negative aspect about this solution is that before showing the main gui, it has to load all the launchable scripts. This means slower startup.
export launch_me='
<button>
 <input file stock="gtk-refresh"></input>
 <action>Refresh:DATE</action>
</button>'

export box='
<vbox>
 <entry><input>date</input><variable>DATE</variable></entry>
 <button><label>launch</label><action type="launch">launch_me</action></button>
</vbox>'

gtkdialog -p box


Imagine that you start a background process to calculate the content of <list>. It will take too long to wait for the result before showing the gui. Imagine that you want to update the content in a gui from a separate app. Okay, here's the trick.....

Gtkdialog updates a progressbar with info from standard output. Most common are the cat and echo commands. First echo "text in bar" (optional), then echo 50 or whatever % integer to define how long the process is come. When a progressbar achieves 100% done (echo 100), it activates its <actions>. So, as long as % is below 100, the actions are not run, but as soon as you echo 100 it will execute your defined actions. What is very good, is that you now can echo 0, and start all over again. Last stage is to define if you want the progressbar shown in your gui. add visible="false" to make it invisible.

Here is a simple example of a clock 
export box='
 <vbox>
 <progressbar visible="false">
  <input>while [ A != B ; do sleep 0.5; P=`cat /tmp/p`;  echo $P; echo 100 > /tmp/p; done</input>
  <action>refresh:ENTRY</action>
  <action>echo 99 > /tmp/p</action>
 </progressbar>
 <entry>
  <variable>ENTRY</variable>
  <input>date +%H:%M:%S</input>
 </entry>
 </vbox>'

gtkdialog -p box


If you want a frequent refreshing of a widget, the <timer> widget was introduced in gtkdialog 0.7.21.
<timer milliseconds="true" interval="500" visible="false">
Gtkdialog misses a tailbox widget, but using this solution it is easy to build our own tailbox.

Both <timer> and <progressbar> widgets uses cpu-power, and in a complex gui this could be a real pitfall. Here follows an explanation of how it is solved in pMusic. It is a way to update a complex gui on non-user actions. User-actions is mouse-clicks and key-entries, and is the common way to interact between user and gui. An example of updating the gui on a non-user-action in pMusic is the loading of id3-tags for files shown in the file-browser....

When clicking on a directory, the browser field refreshes and shows the content of the new directory. Now, pMusic continues with a background process to read the id3 information of the files. When finished, the file-browser should be updated by the new info. - Without the user to click anywhere.

The solution is to either use a <progressbar> which runs its <action> when reaches 100% or a <timer> which acts at a given interval. Older pMusic releases used the <progressbar> solution while recent code uses a <timer>. Both solutions has the downside that they use an amount of cpu power. In a complex gui with several non-user actions this could end up with several cpu-hungry <timers> updating their unique widget(s) of the gui.

pMusic has used 2 <timers> running constantly to update their defined gui-part. You might think that 1 <timer> would be enough, - it could refresh all wanted widgets - it wouldn't harm if the refreshing didn't change anything. BUT, refreshing has an effect on the focus handling. It simply resets the focus, which means that:

The idea of pMusic 2.4.0 was to update all kinds of trackinfo (meta-tags, lyrics, albumart, discography, ...) when a new track starts playing. This would not be possible with the underlaying event-handling in pMusic because it would either suck your cpu-power (with several <timers>), or a global refreshing would make it impossible to be a user (because of focus issues). Also, there is a fact that too many refreshing <action> on a <timer> will increase cpu-usage as well.

So the solution has been to add ONE <timer>, which refreshes a small set of <checkboxes> that (if true) refreshes a single or group of widgets.

<checkboxes> can be set true or false by their <input file>, so we can simply echo true to its <input file>. The <timer> runs its <actions> each second, and the <checkbox> will be refreshed by its <input file>. The code could look like this:
<checkbox visible="false">
 <label>a</label>
 <variable>UPDATE_GUI</variable>
 <input>cat /path/UPDATE_GUI</input>
 <action>if true refresh:PLAYLIST</action>
 <action>if true refresh:ARTWORK</action>
 <action>if true refresh:BUTTON_PLAY</action>
 <action>if true echo false > /path/UPDATE_GUI</action>
</checkbox>

All actions will run only if value is true. To avoid more than one refreshing we reset <input file> and the <checkbox> value to false. Now it will be silent until the next time we echo true > inputfile.

Example script here




5.

The benefits of a config file

A config file is a nice way to store the settings in your program. At next startup, it will show the settings like you left them last time.

Set default status of radiobuttons, Comboboxes...
By default, gtkdialog always activates the first <radiobutton> and the first list-item for <combobox>.

An easy way to use a config file is to run it like an ordinary bash-script, and include variable definitions in it. It is most common to keep config files in home directory as a hidden file ($HOME/.testrc). The file might look like this:
COMBOBOX="item 3"
ENTRY="default text"
RADIOBUTTON1="false"
RADIOBUTTON2="true"


Now let's go to the main script. For the <radiobutton> and the <entry>, we set the <default> tag to the corresponding variable in the config file. Since the <combobox> doesn't support the <default> tag, we need a workaround. We simply build the <combobox> item-list so show our saved variable first.
There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki