Gtkwialog project
Gtkwialog project
Since the new version is currently still under development and not yet published, the notes below only cover some of its original extra functionality.
NOTE: Please refer to post three of this thread for 'Some Tips' for using gtkwialog, and post four for a brief explanation of its operational modes: 1. legacy gtkdialog using system() calls; 2. glib spawned command synchronous blocking; 3. glib spawned command asynchronous non-blocking. There are also a couple of simple example posts in post 4 that may be useful for initial testing purposes.
Why gtkwialog was created.
Legacy gtkdialog <action>command_string</action> uses an underlying C system() call, which used the system's /bin/sh -c contruct to parse and run the action command_string in that shell. (Note that /bin/sh -c takes a command_string as an argument, which can be any valid shell commandline). There are some problems with that C system() call strategy, such that many Puppy app/utils are unable to be used on other Linux systems such as Debian, which uses a dash system shell rather than bash. See post two of this thread, below, for more details and how using gtkwialog provides a solution for the problems.
Main early posts about Gtkwialog development started in this thread:
http://www.murga-linux.com/puppy/viewto ... 214#993214
Later I intend to work on the gtkwialog github site, and once I am satisfied the code is working as I intended, I will change the status to alpha release, upload the source file changes, and let you know when that is ready and where it is - the required changes to original gtkdialog only involve a few source files and a less than a dozen lines of code in each, most of which I basically already detailed during development in the above-linked Gtkdialog Tips thread.
DOWNLOAD LINKS: Usual disclaimers apply concerning suitability of purpose.
New version of gtkwialog is under personal testing. New functions include 'mixed mode: allows use of legacy /bin/sh system traditional gtkdialog mode, with the glib -a and -b modes in same dialog. Particularly useful is that newest version still under development allows running most legacy gtkdialog apps, without any modification, on systems that do not use bash as system shell. Exceptions would include apps that use wrong /bin/sh shebang for code that includes bashisms - these will require the small shebang fix when required. Some details of recent testing here:
http://www.murga-linux.com/puppy/viewto ... 007#998007
Having now established that all ideas/elements of the code basically work as intended, I am currently refactoring the code and completing some of the logic selection elements since there is currently too much code duplication due to the way part of legacy gtkdialog is currently organised.
After that, I have to get it all into git resource repository for likely upload thereafter now that this public dev thread has been unlocked. I hope to finish that current dev work (whether the refactoring proves successful or not) within the next week or maybe two.
wiak
Legacy gtkdialog <action>command_string</action> uses an underlying C system() call, which used the system's /bin/sh -c contruct to parse and run the action command_string in that shell. (Note that /bin/sh -c takes a command_string as an argument, which can be any valid shell commandline). There are some problems with that C system() call strategy:
1. It is NOT recommended to use C system() call for mission critical applications owing to security weaknesses in that relatively simple function call:
https://wiki.sei.cmu.edu/confluence/pag ... d=87152177
2. The mechanism always executes that extra process /bin/sh to activate the command, which is wasteful of resource since some form of fork/exec methodology could instead be used without needing an external shell to be run at all.
3. Many current shell/gtkdialog Puppy apps and utils use bash for the script and bash to export the functions with export -f syntax. Unfortunately, when the construct <action>function_name</action> is then used it cannot work if /bin/sh is dash (because only bash can 'see' the exported function code). Hence Puppy (and the Dogs) currently use an ugly hack: they force /bin/sh to be a symlink to bash. Though bash is powerful as a programming shell, and therefore nice to use for programming the front end of a shell/gtkdialog or shell/gtkwialog Puppy/Dog application/utility, it is very inefficient (slow and resource greedy) as a system level non-interactive shell, which is what the Puppy hack forces it to be. That is why pristine/default Debian and Ubuntu use fast, resource-efficient dash shell for system level activities. Unfortunately, the gtkdialog issue described means that the many Puppy/Dog utilities created using bash/gtkdialog in that manner are unable to be run on default Debian or Ubuntu systems (nor on Slitaz, which uses busybox ash as its default system shell).
4. In gtkdialog, all is not what it seems. For example, if a programmer tries to get round the above issue with <action>bash -c "function_name"</action> what really gets run is:
/bin/sh -c 'bash -c "function_name"'
which not only complicates the programmer's eye view of what to expect, but if /bin/sh is dash, it doesn't work because dash doesn't pass on the main bash script's (parent) environment to the bash -c stage.
-----
How gtkwialog avoids all of the above problems:
1. Gtkwialog, removes that insecure /bin/sh -c system() call altogether in its implementation and instead employs a much more sophisticated glib function to parse the <action>command_string</string> and to execute its command contents entirely without any intermediate /bin/sh invocation. Note that a gtkdialog legacy mode is however also provided for backwards compatibility.
2. Furthermore, the construct <action>bash -c "function_name"</action> works with gtkwialog (i.e. the applications bash script exported functions remain visible so it does not matter if on the system, /bin/sh is dash or ash or bash, the construct will still work now.
3. Finally, since there no longer being any underlying /bin/sh process being executed, what the programmer enters into the <action>command_string</action> is what they actually get. So bash -c "function_name" actually means that(!) and no longer actually means /bin/sh -c 'bash -c "function_name"'. All in all that makes debugging and understanding easier as well as not requiring any ugly hack to force /bin/sh to always point to bash. And programs thus created using gtkwialog are thus compatible to run in pristine/default Debian, Ubuntu and similar, where dash (or even ash) is used as the resource efficient system shell.
4. Gtkwialog is also inherently more efficient than gtkdialog since it does not run that unneeded extra /bin/sh process every time an action command is effected.
------
There are one or two differences in using gtkwialog instead of gtkdialog:
1. If using bash exported functions, the action tab must 'always' use the construct 'bash -c' in order that the bash exported environment is visible and the exported function can be found. That 'always' includes for any underlying system shell being used: ash, dash, AND also for when /bin/sh -> bash. You can't leave out the bash -c when using gtkwialog (which you could with gtkdialog using that awful /bin/sh -> bash hack). But consistency is always better than an ugly hack IMO.
2. Since the /bin/sh -c stage is no longer used, there will probably be some subtle differences in how the <action>command_string</action> is parsed and interpreted. No longer do you have to deal with the likes of /bin/sh -c 'bash -c "functionname"'. Instead, with gtkwialog it is, as I said, a case of what you enter as command_string is what you actually get. So the result is that it should actually be 'easier' to get the code correct (including complex shell quoting) when using gtkwialog.
3. The result of the above differences (and perhaps some others, which I don't know) is that gtkwialog is not exactly backwards compatible with gtkdialog code (except when you run it in 'legacy' mode, when it is identical in operation to legacy gtkdialog). But the end result is inherently more secure, more consistent, more efficient, and results in apps which are more portable across Linux systems.
Using bash -c calls may also have security implications, like legacy gtkdialog system() calls (I do not know the ins and outs of that). However, the fact is, a programmer can avoid calling any such construct when using gtkwialog if they so choose. That is in contrast with legacy gtkdialog when any and every action command evokes a /bin/sh shell process via the insecure C system() function call.
-----------------------
The operational modes of gtkwialog
1. if no -a or -b commandline switch then gtkwialog uses legacy gtkdialog mode (in other words a direct replacement using system() command execution same as legacy gtkdialog exactly). For example:
Code: Select all
<action>viewnior &</action>
Code: Select all
<action>sh -c "viewnior &"</action>
Code: Select all
<action>viewnior</action>
You cannot of course mix modes for the same displayed diagram so programmer chooses which they want for a particular purpose. Of course you could have several dialogs being run from same shell script - each could use different ones of the above modes.
wiak
The above (which was using -b for blocking, synchronous gtkwialog mode) is a good example of how the <action>command_string</action> is a case of what you see is correctly (in terms of expected sh commandline use) what you actually get when using gtkwialog.rcrsn51 wrote:The good news is, backgrounding appears to work with quoting like this:Code: Select all
<action>bash -c "FUNC &"</action>
It the & had been put outside the ("...") quotes then that would of course meant that you were backgrounding the bash -c process rather than the probably intended FUNC you were calling up.
-----
Here is a practical example of converting an existing Puppy/Dog utility with gtkwialog -b mode such that it will also now be compatible with systems not running bash as their /bin/sh system shell:
To avoid having to type /bin/bash -c often you could simply use:fredx181 wrote:I took existing script gdrive-gui2 (google-drive filemanager, my mod of mikeb's dropbox_gui) which is pretty complicated and having many "export -f " required functions.
So I changed all exported functions to "bash -c <function>" but one mistake, I made this(setting variable BUTTON):That didn't work, took me a while to realize it had to be this:Code: Select all
<action>BUTTON=3; bash -c add_selection</action>
Ran the script after changing to sh > dash and everything OK.Code: Select all
<action>bash -c "BUTTON=3; add_selection"</action
Also ran the same modified script with sh > bash: also works OK.
b="/bin/bash -c"; export b
and then use $b (suitably quoted) in <action>$b rest_of_command_string</action>
---------
If you are worried about using /bin/bash -c constructs in terms of security (which I'm not, but admittedly don't really know the security implications, if any, of using bash -c) then you could use something like step suggested (this being my example to illustrate his excellent algorithm with gtkwialog, here using -b glib command spawning blocking-mode):
Code: Select all
#!/bin/sh
#Functions
sub_now (){
date > /tmp/date
}
#you avoid using export -f since a bashism
sub_filemanager (){
pcmanfm &
}
#Variables
program="$0"; export program
script='
<vbox>
<entry>
<variable>ENTRY_DATE</variable>
<input>cat /tmp/date</input>
</entry>
<button>
<label>Refresh</label>
'" <action>$program @now</action> "'
<action>refresh:ENTRY_DATE</action>
</button>
<button>
<input file stock="gtk-home"></input>
'" <action>$program @filemanager</action> "'
</button>
</vbox>'
export script
#Main body - this is step's main pattern along with recalling the script
case $1 in
@*) sub=sub_${1#@}; shift; $sub "$@"; exit $? ;; # relay sub_func'ions
# add cases for typical script option parsing, i.e., --help, -x, etc.
esac
gtkwialog -b -p script
-------------
@rcrsn51: As I explained, when in standard -b (blocking mode) with gtkwialog, for the above, you need to use <action>sh -c "viewnior &"</action> since it is a shell that provided job control. However:rcrsn51 wrote:I am running the 64bit version. The "bash -c FUNC" structure is working correctly, but here is a problem:
This should pop up a window running viewnior as a backgrounded process.Code: Select all
<action>viewnior &</action>
Instead, viewnior interprets the "&" as a non-existent file, and opens in a non-backgrounded window with a "file not found" message.
With the new gtkwialog -a (asynchronous non-blocking mode) you can simply use <action>viewnior</action>. Note however, that legacy gtkdialog always uses blocking-mode, albeit via system() mechanism, so using this gtkwialog -a non-blocking mechanism will not always give expected results with other xml constructs (refreshing widget variables, for example, may not work as expected since non-blocked means instant return. That's not any kind of bug; it is up to the script writer to use -a option only when it is useful (and extra user code can address timing differences anyway), but -b will provide more familiar behaviour. You cannot mix -a and -b on the same dialog of course - but you can have different dialogs in your script, some with -a mode and some with -b mode.
wiak
The operational modes of gtkwialog
Just put the appropriate (32bit or 64bit) gtkwialog into your executable PATH first.
Code: Select all
#!/bin/bash
sub_filemanager (){
rox &
}
export -f sub_filemanager
script='
<vbox>
<entry>
<variable>MYENTRY</variable>
<input>ls -al /bin/sh</input>
</entry>
<hbox width-request="480">
<text><label>Open filemanager:</label></text>
<button>
<input file stock="gtk-home"></input>
<action>bash -c sub_filemanager</action>
</button>
<button ok></button>
</hbox>
</vbox>'
export script
gtkwialog -b -p script
Code: Select all
#!/bin/sh
# Simple Example to show the subtle difference in
# <action>command_strings for the three modes
# available in gtkwialog.
# You can substitute viewnior for gpicview, for example, if you want.
# After you close the first window, the next of the three will open:
mode_gtkdialog_legacy='
<vbox>
<hbox>
<text><label>Open image viewer:</label></text>
<button>
<input file stock="gtk-home"></input>
<action>gpicview &</action>
</button>
<button ok></button>
</hbox>
</vbox>'
export mode_gtkdialog_legacy
mode_synchronous_blocking='
<vbox>
<hbox>
<text><label>Open image viewer:</label></text>
<button>
<input file stock="gtk-home"></input>
<action>sh -c "gpicview &"</action>
</button>
<button ok></button>
</hbox>
</vbox>'
export mode_synchronous_blocking
mode_asynchronous_nonblocking='
<vbox>
<hbox>
<text><label>Open image viewer:</label></text>
<button>
<input file stock="gtk-home"></input>
<action>gpicview</action>
</button>
<button ok></button>
</hbox>
</vbox>'
export mode_asynchronous_nonblocking
# popup mode_gtkdialog_legacy example window
gtkwialog -p mode_gtkdialog_legacy
# popup mode_synchronous_blocking example window
gtkwialog -b -p mode_synchronous_blocking
# popup mode_asynchronous_nonblocking example window
gtkwialog -a -p mode_asynchronous_nonblocking
exit 0
Trying to see if I can get some of the Gtkdialog Tips example scripts working.
Here are some modded to gtkwialog example scripts that seem to work (will add to these over time). Numbered as in Gtkdialog Tips. Some of these need closed using Ctrl-C from the commandline:
4.) Let external code act on your gtkdialog gui
Code: Select all
#!/bin/sh
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>'
gtkwialog -b -p box
Code: Select all
#!/bin/sh
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>sh -c "echo 99 > /tmp/p"</action>
</progressbar>
<entry>
<variable>ENTRY</variable>
<input>date +%H:%M:%S</input>
</entry>
</vbox>'
gtkwialog -b -p box
Set default status of Radiobuttons, Comboboxes..
Code: Select all
#!/bin/bash
#in case no testc file (first run), build the file
[ ! -s $HOME/.testrc ] && echo -e -n 'COMBOBOX="item 3"\nENTRY="default text"\nRADIOBUTTON1="false"\nRADIOBUTTON2="true"\n' > $HOME/.testrc
. $HOME/.testrc
#define combobox list items
COMBOBOX_ITEMS="<item>$COMBOBOX</item>" #stored value should be first in list
for I in 1 2 3 4; do COMBOBOX_ITEMS=`echo "$COMBOBOX_ITEMS<item>item $I</item>"`; done
export main="
<window title=\"The benefits of a config file\">
<vbox>
<frame The first item of list is the default choice in a Combobox>
<combobox>
<variable>COMBOBOX</variable>
$COMBOBOX_ITEMS
</combobox>
</frame>
<frame If nothing else is set, the first radiobutton is the active one>
<radiobutton>
<variable>RADIOBUTTON1</variable>
<label>Yes I am</label>
<default>$RADIOBUTTON1</default>
</radiobutton>
<radiobutton>
<variable>RADIOBUTTON2</variable>
<label>No I'm not</label>
<default>$RADIOBUTTON2</default>
</radiobutton>
</frame>
<frame Fetch entry-value from config file>
<entry>
<variable>ENTRY</variable>
<default>$ENTRY</default>
</entry>
</frame>
<hbox>
<button ok></button>
</hbox>
</vbox>
</window>"
gtkwialog -bp main > $HOME/.testrc
Refresh image
Code: Select all
#!/bin/sh
export MAIN='
<window>
<vbox>
<pixmap>
<variable>IMAGE</variable>
<input file>/root/image1.png</input>
</pixmap>
<button>
<label>Change image</label>
<action>sh -c "cp -f /root/image2*.png /root/image1.png"</action>
<action type="refresh">IMAGE</action>
</button>
</vbox>
</window>'
gtkwialog -b --center --program=MAIN
Code: Select all
#!/bin/bash
#Code below line 15 (break:) is activated when user move item in list
ls -1 /usr/share/applications > /tmp/test
do_something () { Xdialog -info "Do something with\n$TREE" x 2000 ;} ; export -f do_something
echo '
<vbox>
<tree headers-clickable="false" reorderable="true">
<label>Backgrounds</label>
<input>cat /tmp/test</input>
<output file>/tmp/test</output>
<variable>TREE</variable>
<height>300</height><width>200</width>
<action>bash -c "do_something &"</action>
<action signal="button-release-event" condition="command_is_true( echo $PTR_Y )">break:</action>
<action signal="button-release-event">save:TREE</action>
<action signal="button-release-event">activate:BTN_SAVE</action>
</tree>
<button visible="false">
<variable>BTN_SAVE</variable>
<action>cp /tmp/test /tmp/testbackup</action>
<action>save:TREE</action>
<action condition="command_is_true([[ $(wc </tmp/test) != $(wc </tmp/testbackup) ]] && sed \"s/^|*//\" /tmp/testbackup > /tmp/test && echo true )">refresh:TREE</action>
</button>
</vbox>' | gtkwialog -b -s
Code: Select all
#!/bin/bash
move (){
PRESS_EVENT=$(cat /tmp/PRESS_EVENT)
[[ $PRESS_EVENT && $TREE ]] || exit #exit if at least one of the 2 values is empty
[[ $PRESS_EVENT == $TREE ]] && exit #exit if both are equal (=single or double click)
sed -i "/$PRESS_EVENT/d; /$TREE/ i\\$PRESS_EVENT" /tmp/list #remove PRESS_EVENT, then insert item PRESS_EVENT before item $TREE
}
export -f move
ls -1 /usr/share/applications > /tmp/list
export test="
<tree rules_hint=\"true\" hover-selection=\"true\" tooltip-text=\"Drag'n drop items to move them in list\">
<label>Backgrounds</label>
<input>cat /tmp/list</input>
<variable>TREE</variable>
<height>300</height><width>200</width>
<action signal=\"button-press-event\">sh -c \"echo \$TREE > /tmp/PRESS_EVENT\"</action>
<action signal=\"button-release-event\">bash -c move</action>
<action signal=\"button-release-event\">refresh:TREE</action>
</tree>"
gtkwialog -bp test
Code: Select all
#!/bin/bash
export MAIN_DIALOG='
<vbox>
<text>
<label>"Enter a number (text will default to 0)"</label>
</text>
<entry editable="true" allow-empty="false">
<input>case $ENTRY in ""|*[^0-9]*) echo 0;; *) echo $ENTRY ;; esac</input>
<variable>ENTRY</variable>
<action signal="focus-out-event">refresh:ENTRY</action>
</entry>
<text>
<label>"Enter a number within [5,15], otherwise:
input will be capped at 15,
floored at 5,
or set to 10 in case of text input"</label>
</text>
<entry editable="true" allow-empty="false">
<input>A=$ENTRY2; case $A in [0-9]*) [[ $A -gt 15 ]] && echo 15 || [[ $A -lt 5 ]] && echo 5 || echo $A ;; *) echo 10;; esac</input>
<variable>ENTRY2</variable>
<action signal="focus-out-event">refresh:ENTRY2</action>
</entry>
<button ok></button>
</vbox>'
gtkwialog -b -p MAIN_DIALOG
unset MAIN_DIALOG
Code: Select all
#!/bin/sh
#Splash
echo 0 > /tmp/splash
export SPLASH='
<window title="PCC" icon-name="gtk-preferences" resizable="false" decorated="false">'"
<vbox>
<pixmap><input file>/usr/share/icons/hicolor/48x48/apps/wex48.png</input></pixmap>
<text height-request=\"50\" use-markup=\"true\"><label>\"<b><span size='"'x-large'"' color='"'orange'"'>Puppy Control Center</span></b>\"</label></text>"'
<progressbar visible="true">
<label>nn</label>
<input>while [ "$M" != "100" ]; do M=$(cat "/tmp/splash"); [ "$M" != "100" ] && M=$(( M + 4 )); echo "$M"|tee "/tmp/splash"; sleep 1; done</input>
<action type="exit">Ready</action>
</progressbar>
</vbox></window>'
gtkwialog -bp SPLASH --center &
sleep 10 #well, this is to simulate some startup processes....
export GUI='
<window title="PCC" icon-name="gtk-preferences" width-request="800">
<vbox>
<text height-request="200">
<label>Hello, welcome to the Puppy Control Center</label>
</text>
<hbox>
<button ok>
</button>
</hbox>
</vbox>
</window>'
gtkwialog -bp GUI
echo 100 >/tmp/splash
sleep 1
rm /tmp/splash
Code: Select all
<action>viewnior &</action>
Instead, viewnior interprets the "&" as a non-existent file, and opens in a non-backgrounded window with a "file not found" message.
Well, that is to be expected for that kind of example. There is no shell process ever started up by gtkwialog itself (unlike C system() call method of legacy gtkdialog). The action command_string is simply parsed (as if by a UNIX shell, but actually just by a function) and the command then run (fork/executed). It is up to the programmer if they want to use & (which needs a shell process for backgrounding as part of the overall <action>command_string</action>):rcrsn51 wrote:This should pop up a window running viewnior as a backgrounded process.Code: Select all
<action>viewnior &</action>
Instead, viewnior interprets the "&" as a non-existent file, and opens in a non-backgrounded window with a "file not found" message.
Code: Select all
<action>sh -c "viewnior &"</action>
Code: Select all
<action>sh -c viewnior &</action>
EDIT: For example, compare the different result of:
Code: Select all
<action>sh -c "sleep 10" &</action>
Code: Select all
<action>sh -c "sleep 10 &"</action>
As I said, with gtkwialog, what you enter is what you get. You need to run a shell if you want to background a command. I am sure you know that job control is one of the main usual functions of a shell.
Using system() is insecure because the command runs in a shell that inherited the parent's environment. If a malicious user inserted something bad into the environment, it could alter how the command runs.
Using fork()+execve() is more secure because the parent can sanitize the environment that it passes to the forked child process.
But it is the responsibility of the parent program to provide that sanitizing code. In the case of gtkwialog, it doesn't know in advance what command is going to run and what sanitizing is required.
So I suspect that gtkwialog just passes along its own parent's environment. In which case, it is no more secure than system().
- misko_2083
- Posts: 114
- Joined: Tue 08 Nov 2016, 13:42
Speaking of sleep, if next action is run from a button put geany on top of gtkwialog window and then gtkwialog is put back in focus, gtkwialog will be empty/unusable until the sleep ends. It seems the window is being redrawn only when the command ends.wiak wrote:rcrsn51 wrote: EDIT: For example, compare the different result of:
andCode: Select all
<action>sh -c "sleep 10" &</action>
in terms of watching the processes in action with LxTask or similar. I think the first one actually backgrounds the whole shell command (which can't return till the sleep finishes) whilst the second just backgrounds the sleep process running within the shell (and therefore can return leaving the sleep running in the background) (?)Code: Select all
<action>sh -c "sleep 10 &"</action>
Code: Select all
<action>bash -c "geany & sleep 10;"</action>
Code: Select all
<action>bash -c "geany & wait $!"</action>
But, to me, this is just 'normal' expected commandline process behaviour. In the first of the above, you run geany and background it, but you also run a 10 second sleep without backgrounding it. bash cannot return to the commandline till its child sleep process is finished. (That reflects in the gtkwialog GUI being inactive till bash returns).misko_2083 wrote: Speaking of sleep, if next action is run from a button put geany on top of gtkwialog window and then gtkwialog is put back in focus, gtkwialog will be empty/unusable until the sleep ends. It seems the window is being redrawn only when the command ends.Next command will make it unusable until geany is closed.Code: Select all
<action>bash -c "geany & sleep 10;"</action>
Code: Select all
<action>bash -c "geany & wait $!"</action>
Similarly for your second example; try at a console commandline:
Code: Select all
geany & wait $!
Like I said, what you put in is what you get in terms of correct shell/process behaviour. Of course working out what the shell is going to do with complex commands is often more than a bit tricky but you can just try the commands at the commandline first before using inside gtkwialog <action> tags.
EDIT: In both legacy gtkdialog and gtkwialog the <action> command is blocked unless told to background. That's part of C system() functionality (waits till child process started finished) and also part of glib's g_spawn_command_line_sync function I use in gtkwialog as an alternative. I did try a version of that command that does not block waiting by the way, but I decided to mimic gtkdialog as much as possible in that way in order for Refresh widget timings to work the same. I may experiment with that non-blocking version too sometime - the problem becomes how to block when you want to and wait construct with sh might do that job in that case right enough.
wiak
- misko_2083
- Posts: 114
- Joined: Tue 08 Nov 2016, 13:42
I thought it would disable the button until the process is terminated.wiak wrote: But, to me, this is just 'normal' expected commandline process behaviour. In the first of the above, you run geany and background it, but you also run a 10 second sleep without backgrounding it. bash cannot return to the commandline till its child sleep process is finished. (That reflects in the gtkwialog GUI being inactive till bash returns).
Similarly for your second example; try at a console commandline:
The result is to be expected (bash has to wait till its child process, geany, completes before can return). Just normal shell process handling, not a feature or disadvantage of gtkwialog.Code: Select all
geany & wait $!
wiak
So if there are more commands of which none should wait, just fork them all.
Code: Select all
bash -c "(geany & sleep 10; echo hi) &"
Exactly. By the way I did EDIT and add a bit of explanation in previous post (whilst you were posting):misko_2083 wrote:
So if there are more commands of which none should wait, just fork them all.Code: Select all
bash -c "(geany & sleep 10; echo hi) &"
This bit I mean:
EDIT: In both legacy gtkdialog and gtkwialog the <action> command is blocked unless told to background. That's part of C system() functionality (waits till child process started finished) and also part of glib's g_spawn_command_line_sync function I use in gtkwialog as an alternative. I did try a version of that command that does not block waiting by the way, but I decided to mimic gtkdialog as much as possible in that way in order for Refresh widget timings to work the same. I may experiment with that non-blocking version too sometime - the problem becomes how to block when you want to and wait construct with sh might do that job in that case right enough. EDIT2 But I had my doubts and so moved on without further consideration.
Tested now on 64-bit, using the same script I modified for use with gtkwialog (google-drive filemanager) as I described in the other thread and results are the same, all working as expected.
Also tested "debdog-install", don't know if it's useful info, anyway I knew already (by testing earlier) that it works OK also in case dash > sh, out of curiosity replaced in the script the gtkdialog instances with gtkwialog, ran it and works fine.
Thanks again for your efforts !
Fred
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
FWIW, using the glib spawn functions instead of system and popen, may make gtkwialog portable to windows if anyone wants to give it a go.
Edit: here is a link to the conveniently forgotten gtk bug
https://web.archive.org/web/20100510072 ... bleSignals
BTW, this is one of many reasons I stopped using gtk. If Redhat doesn't use it for their enterprise distro, it gets dropped.
http://www.murga-linux.com/puppy/viewto ... 539#993539
Disciple is/seems a nice guy and meant no harm in a few comments he wrote; I understand that (and indeed, the overall impression was that he was keen that Puppy adopt gtkwialog approach, albeit not forked), but, sorry, I do expect actual trouble from some on this forum. Whether everyone would like to adopt gtkwialog 'approach' is another matter (and no concern of mine per se); this is Puppy forum... so I doubt that very much, and may be there are good reasons not to (I am not stating an opinion).
I'll keep on with my coding, and see how it goes. Actually, I'm planning to incorporate (via commanline switches) several difference mechanisms into my experimental version, because there is a non-blocking (rather than existing blocking) glib spawn mechanism (including the gtkdialog original) that I'd like to have available for use at times too (I've already tried it). When using that non-blocking mechanism I (think) I will no longer need to use a shell to effect backgrounding (&) operation.
EDIT: Basically, in more detail, my plan (started to be actioned early today following some thought about the needs and hows) is that with appropriate commandline switch gtkwialog will use (my favourite) glib blocking spawn mechanism (like current gtkwialog, so just a minor operational change - a gtkwialog --switch [-b] will be needed on commandline) and with other commandline switch [-a] will instead use glib unblocking spawn mechanism (to hopefully allow &-like backgrounding without needing shell process) and for no extra commandline switch, it will use legacy-compatible mechanism (which some might find contentious). But now, and 'maybe later', I like that the slightly different name differentiates from legacy versions - at least the user is then clear on the different facilities that are available. Furthermore, I may well want to diverge in functionality further from legacy gtkdialog (Puppy gtkdialog may want to diverge in ways I don't) - For now, I'll just do all these things for my own experiment/versions to avoid the dangers of tinkering with official code (and I don't want to ask permission to have my ideas approved by some authority - this is just an experimental fork for my own home desired purposes actually.
However, more than these simple additions I really, on the whole, do not 'intend' adding any further extra ever (though as I've said it is dodgy to ever say never is never). Main thing is I don't want to add bloat and I want backward's compatibility (as far as I technically can manage, which seems likely to me in this case), and stability - too much change is a bad thing I feel (I'm getting old?). I'm tired now (always tired these days) so will hang up the computer for a little while now (as long as my addiction allows me that escape anyway).
wiak
Note how "/bin/sh" is baked into the system() function. That suggests that in order for a legacy gtkdialog app (with exported functions) to run in a non-bash environment, /bin/sh would need to be re-linked to /bin/bash.
Meaning that you would effectively have to force the whole environment back into bash.
Bill
I'm not sure what you are getting at. As you know I've stated already how C system() call uses /bin/sh -c (I've read the source code already).
http://www.murga-linux.com/puppy/viewto ... 108#993108
That indeed is why exported bash functions (using export -f) can only be used with legacy gtkdialog when /bin/sh is forcibly symlinked to bash. Fred did try some techniques to automate that for only when legacy gtkdialog app was actually running, and whilst his attempt seemed promising at the time, it ended with some show-stopper or other. You'd have to ask Fred more about that one since I've forgotten the link and details.
Oh here it is, Fred mentioned his attempt more recently in same thread as above link:
wiakFred wrote:But don't get me wrong, I'd love to have it like standard Debian with sh > dash, maybe you remember I've tried in the past by using "switchsh", but didn't work out.
http://murga-linux.com/puppy/viewtopic. ... 995#924995
Download link at first post of this thread.
Only if you really know what you are doing, and at your own risk: You should be able to replace your existing legacy gtkdialog binary and use this one instead (perhaps via gtkdialog as symlink to gtkwialog) and existing shell/gtkdialog apps should work out of the box. However, new apps or modded apps are recommended to use the -b switch to put gtkwialog into glib sync command spawning blocking mode (which is mode used in previous gtkwialog release). DISCLAIMER: I am not suggesting you do replace your existing gtkdialog - this release of gtkwialog is indicated as being prealpha on purpose - it is not any kind of official release; only for testers who know what they are doing. Per the usual disclaimers and caveats, the program is not guaranteed to be fit for purpose. However, working fine in all my own tests so far.wiak wrote: New versions, which will use legacy gtkdialog mode (which uses system() call) if no commandline switch -b or -a provided:
NOTE WELL: The usual preferred mode is however to generally to use with -b switch as described below.
Compiled on XenialDog64 and XenialDog32
gtkwialog_prealpha64n (64bit version):
gtkwialog_prealpha32n (32bit version):
To get gtkwialog mode of previous release, you need to run the command with
followed by any other gtkwialog options you need (such as -p)Code: Select all
gtkwialog -b
The -b stands for use 'blocking', which uses glib sync mode command spawning.
Alternatively, if you run it with:
The -a stands for use (non-blocking) glib async mode command spawning (which can start up a program in the background without needing shell & symbol. However, that mode returns immediately, which will likely not be desired response with most legacy bash/gtkdialog apps).Code: Select all
gtkwialog -a etc...
At least the different name, "Gtkwialog", also removes the confusion some people have between legacy "Gtkdialog", the GUI building utility, and GtkDialog the name of the Gtk library code that provides the underlying functionality... i.e. comments I've read, such as: oh, I though gtkdialog was provided as part of Gtk
As far as further development is currently concerned: All going well, the only thing left to be done is to update the help text for gtkwialog --help. Obviously I don't want to muck with that yet until program testing shows all good.
@rcrsn51: As I explained, when in standard -b (blocking mode) with gtkwialog, for the above, you need to use <action>sh -c "viewnior &"</action> since it is a shell that provided job control. However:rcrsn51 wrote:I am running the 64bit version. The "bash -c FUNC" structure is working correctly, but here is a problem:
This should pop up a window running viewnior as a backgrounded process.Code: Select all
<action>viewnior &</action>
Instead, viewnior interprets the "&" as a non-existent file, and opens in a non-backgrounded window with a "file not found" message.
With the new gtkwialog -a (asynchronous non-blocking mode) you can simply use <action>viewnior</action>. Note however, that legacy gtkdialog always uses blocking-mode, albeit via system() mechanism, so using this gtkwialog -a non-blocking mechanism will not always give expected results with other xml constructs (refreshing widget variables, for example, may not work as expected since non-blocked means instant return. That's not any kind of bug; it is up to the script writer to use -a option only when it is useful (and extra user code can address timing differences anyway), but -b will provide more familiar behaviour. You cannot mix -a and -b on the same dialog of course - but you can have different dialogs in your script, some with -a mode and some with -b mode. Lots to try out and test...
Note that I've slightly modified post three ("Some tips") of this thread to account for the new -a and -b command spawn modes of gtkwialog.
wiak
-
- Posts: 721
- Joined: Sat 31 Mar 2018, 08:01
- Location: Rakaia
- Contact:
I have made a Wiki entry for Gtkwialog.
http://www.puppylinux.org/wikka/Gtkwialog
Any changes you wish made to the entry please let me know.