Revision history for gtkdialogDocTips3
Additions:
===@@**#%[[gtkdialogDocTips2|❰❰❰ Previous]]#% #%[[gtkdialogDocTips|Index]]#% #%[[gtkdialogDocTips4.1|Next ❱❱❱]]#%**@@===
Deletions:
Additions:
[[HomePage]] > [[SoftwareIndex|Software Index]] > [[SoftwareDevelopment|Development]] > [[gtkdialog|gtkdialog]] > [[gtkdialogDocTips|Tips and Tricks]]
Gtkdialog updates a [[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar 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.
If you want a frequent refreshing of a widget, the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## widget was introduced in gtkdialog 0.7.21.
Both ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## and ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar <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....
The solution is to either use a ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar <progressbar>]]## which runs its ##<action>## when reaches 100% or a ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## which acts at a given interval. Older pMusic releases used the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar <progressbar>]]## solution while recent code uses a ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <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 ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <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:
- scrolling in ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/table <table>]]## is moved to top.
- what you are about to write in an ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/entry <entry>]]## is cleared.
- Your selected item in the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/tree <tree>]]## is not selected anymore
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 ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## will increase cpu-usage as well.
So the solution has been to add ONE ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]##, which refreshes a small set of ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkboxes>]]## that (##if true##) refreshes a single or group of widgets.
##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkboxes>]]## can be set ##true## or ##false## by their ##<input file>##, so we can simply ##echo true## to its ##<input file>##. The ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## runs its ##<actions>## each second, and the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkbox>]]## will be refreshed by its ##<input file>##. The code could look like this:
All actions will run only if value is ##true##. To avoid more than one refreshing we reset ##<input file>## and the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkbox>]]## value to false. Now it will be silent until the next time we ##echo true > inputfile##.
Gtkdialog updates a [[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar 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.
If you want a frequent refreshing of a widget, the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## widget was introduced in gtkdialog 0.7.21.
Both ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## and ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar <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....
The solution is to either use a ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar <progressbar>]]## which runs its ##<action>## when reaches 100% or a ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## which acts at a given interval. Older pMusic releases used the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/progressbar <progressbar>]]## solution while recent code uses a ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <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 ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <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:
- scrolling in ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/table <table>]]## is moved to top.
- what you are about to write in an ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/entry <entry>]]## is cleared.
- Your selected item in the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/tree <tree>]]## is not selected anymore
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 ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## will increase cpu-usage as well.
So the solution has been to add ONE ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]##, which refreshes a small set of ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkboxes>]]## that (##if true##) refreshes a single or group of widgets.
##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkboxes>]]## can be set ##true## or ##false## by their ##<input file>##, so we can simply ##echo true## to its ##<input file>##. The ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/timer <timer>]]## runs its ##<actions>## each second, and the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkbox>]]## will be refreshed by its ##<input file>##. The code could look like this:
All actions will run only if value is ##true##. To avoid more than one refreshing we reset ##<input file>## and the ##[[https://github.com/puppylinux-woof-CE/gtkdialog/wiki/checkbox <checkbox>]]## value to false. Now it will be silent until the next time we ##echo true > inputfile##.
Deletions:
Gtkdialog updates a [[http://01micko.com/reference/progressbar.html 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.
If you want a frequent refreshing of a widget, the ##[[http://01micko.com/reference/timer.html <timer>]]## widget was introduced in gtkdialog 0.7.21.
Both ##[[http://01micko.com/reference/timer.html <timer>]]## and ##[[http://01micko.com/reference/progressbar.html <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....
The solution is to either use a ##[[http://01micko.com/reference/progressbar.html <progressbar>]]## which runs its ##<action>## when reaches 100% or a ##[[http://01micko.com/reference/timer.html <timer>]]## which acts at a given interval. Older pMusic releases used the ##[[http://01micko.com/reference/progressbar.html <progressbar>]]## solution while recent code uses a ##[[http://01micko.com/reference/timer.html <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 ##[[http://01micko.com/reference/timer.html <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:
- scrolling in ##[[http://01micko.com/reference/table.html <table>]]## is moved to top.
- what you are about to write in an ##[[http://01micko.com/reference/entry.html <entry>]]## is cleared.
- Your selected item in the ##[[http://01micko.com/reference/tree.html <tree>]]## is not selected anymore
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 ##[[http://01micko.com/reference/timer.html <timer>]]## will increase cpu-usage as well.
So the solution has been to add ONE ##[[http://01micko.com/reference/timer.html <timer>]]##, which refreshes a small set of ##[[http://01micko.com/reference/checkbox.html <checkboxes>]]## that (##if true##) refreshes a single or group of widgets.
##[[http://01micko.com/reference/checkbox.html <checkboxes>]]## can be set ##true## or ##false## by their ##<input file>##, so we can simply ##echo true## to its ##<input file>##. The ##[[http://01micko.com/reference/timer.html <timer>]]## runs its ##<actions>## each second, and the ##[[http://01micko.com/reference/checkbox.html <checkbox>]]## will be refreshed by its ##<input file>##. The code could look like this:
All actions will run only if value is ##true##. To avoid more than one refreshing we reset ##<input file>## and the ##[[http://01micko.com/reference/checkbox.html <checkbox>]]## value to false. Now it will be silent until the next time we ##echo true > inputfile##.
Additions:
@@**#%[[gtkdialogDocTips2|❰❰❰ Previous]]#% #%[[gtkdialogDocTips|Index]]#% #%[[gtkdialogDocTips4.1|Next ❱❱❱]]#%**@@
Deletions:
Additions:
@@**#%[[gtkdialogDocTips2|❰❰❰ Previous]]#% #%[[gtkdialogDocTips|Index]]#% #%[[gtkdialogDocTips4|Next ❱❱❱]]#%**@@
Additions:
----
==Categories==
CategoryGtkdialog
==Categories==
CategoryGtkdialog
No Differences
Additions:
[[HomePage]] > [[SoftwareIndex Software Index]] > [[SoftwareDevelopment Development]] > [[gtkdialog gtkdialog]] > [[gtkdialogDocTips Tips and Tricks]]
Deletions:
Additions:
[[HomePage]] > [[SoftwareIndex Software Index]] > [[SoftwareDevelopment Development]] > [[gtkdialog gtkdialog]] > [[gtkdialogDoc documentation]] > [[gtkdialogDocTips Tips and Tricks]]
====3. Let external code act on your gtkdialog gui====
====3. Let external code act on your gtkdialog gui====
Deletions:
======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. [[http://wikka.puppylinux.com/gtkdialogDoc#hn_1. Where to start]]** - links to documentation and examples.
**2. [[http://wikka.puppylinux.com/gtkdialogDoc#hn_2. Syntax]]** - How to use variables in the code.
**3. [[http://wikka.puppylinux.com/gtkdialogDoc#hn_3. Let the script return data]]** - Choose a proper coding structure.
**4. [[http://wikka.puppylinux.com/gtkdialogDoc#hn_4. Let external code act on your gtkdialog gui]]**
**5. [[http://wikka.puppylinux.com/gtkdialogDoc#hn_5. The benefits of a config file]]**
- Set default status of Radiobuttons, Comboboxes...
- How to store window size/placement
**6. Speed issues** - Let your turtle run
**7. Extended use of widgets** - Undocumented features
**8. Advanced Syntax** - make your code readable
- Comments in your code.
- Include code if.......
**9. Text managing**
**10. Tips and tricks**
- How to change the gui without restarting the app
- Control the icon/label of menuitems.
- Understand the alignment.
- Window header icon.
- Refresh image
- Drag'n drop.
- Hotkeys.
- Set a fixed size of a progressbar.settings
- Define unique gtk-theme.
- Override window manager - skip taskbar, sticky, layer, border
- Let entry accept (some) numbers only.
- MIME.
- Checkbox with image
- Use a splash screen.
- Press 'Enter' instead of clicking the 'Ok' button.
**Tips and tricks - Links**
- [[https://web.archive.org/web/20200524085209/http://murga-linux.com/puppy/viewtopic.php?p=588570#588570 Transparent background (gtkdialog desklets)]]
- [[http://blog.puppylinux.com/archive/current.php?post=posts/30-Gtkdialog-right-click-menu.html Right-click menu]]
- [[http://blog.puppylinux.com/archive/current.php?post=posts/20-gtkdialog-knob.html Knob]]
- [[http://blog.puppylinux.com/archive/current.php?post=posts/40-Gtkdialog---Dynamic-tabs.html Dynamic tabs]]
- ++[[https://web.archive.org/web/20200524085209/http://murga-linux.com/puppy/viewtopic.php?t=115140 Calendar]]++
- ++[[https://web.archive.org/web/20200524085209/http://murga-linux.com/puppy/viewtopic.php?t=107675 Chooser - navigate by pressing keys]]++
====1.====
====Where to start====
Most importantly, Thunor has written a comprehensive [[http://01micko.com/reference/ 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 [[http://www.tecmint.com/gtkdialog-create-graphical-interfaces-and-dialog-boxes/ here]] and [[http://pclosmag.com/html/Issues/200910/page21.html here]]
⚫ [[https://code.google.com/archive/p/gtkdialog/ Examples]] are often easier to understand.
⚫ [[http://xpt.sourceforge.net/techdocs/language/gtkdialog/gtkde03-GtkdialogUserManual/ General documentation]] of gtkdialog is poor, but it's a start.
⚫ The command 'gtkdialog --help' shows available parameters.
⚫ Get the gtkdialog code
- [[https://github.com/01micko/gtkdialog Source code]]
- [[https://web.archive.org/web/20200524085209/http://murga-linux.com/puppy/viewtopic.php?p=538294#538294 Compile info]]
- [[https://web.archive.org/web/20200524085209/http://murga-linux.com/puppy/viewtopic.php?p=707526#707526 Pets]]
- Note! woodenshoe-wi has fixed the [[https://github.com/woodenshoe-wi/gtkdialog/releases sourcecode to work with GTK3]]
====2.====
====Syntax====https://web.archive.org/web/20200524085209/
The basics of building a simple gui is told by the links in chapter [[http://wikka.puppylinux.com/gtkdialogDoc#hn_1. 1.]] You should have played a little bit before you continue.
About QUOTES ( **{{color text=""" c="red"}}** and **{{color text="'" c="red"}}** )
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=**{{color text=""" c="red"}}**<window title=\"Psync\"...........</window>**{{color text=""" c="red"}}**##
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=**{{color text="'" c="red"}}**<window title=\"Psync\"...........</window>**{{color text="'" c="red"}}**##
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=**{{color text=""" c="red"}}**<window title=\"$TITLE\"...........</window>**{{color text=""" c="red"}}**##
returns
~##<window title="Psync"...........</window>##
while
~##export Psync=**{{color text="'" c="red"}}**<window title="$TITLE"...........</window>**{{color text="'" c="red"}}**##
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:
- Do you want to continue?
- Please choose item in list
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='
<text><label>Are you sure?</label></text>
<hbox>
<button no></button>
<button yes><action>EXIT:sure</action></button>
</hbox>
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='
<variable>ENTRY_DATE</variable>
<input>cat /tmp/date</input>
<button>
<label>Refresh</label>
<action>now</action>
<action>refresh:ENTRY_DATE</action>
</button>
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='
<variable>ENTRY_DATE</variable>
<input>cat /tmp/date</input>
<button>
<label>Refresh</label>
<action>/root/test -now</action>
<action>refresh:ENTRY_DATE</action>
</button>
I=$IFS; IFS=""
for STATEMENTS in $(gtkdialog -p script); do
eval $STATEMENTS
done
IFS=$I
====4.====
====Let external code act on your gtkdialog gui====
====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 ##[[http://01micko.com/reference/radiobutton.html <radiobutton>]]## and the first list-item for ##[[http://01micko.com/reference/combobox.html <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 ##[[http://01micko.com/reference/radiobutton.html <radiobutton>]]## and the ##[[http://01micko.com/reference/entry.html <entry>]]##, we set the ##<default>## tag to the corresponding variable in the config file. Since the ##[[http://01micko.com/reference/combobox.html <combobox>]]## doesn't support the ##<default>## tag, we need a workaround. We simply build the ##[[http://01micko.com/reference/combobox.html <combobox>]]## item-list so show our saved variable first.
