Gtkwialog project

[wiak]

I've translated quite a few of the gtkdialog examples from zigbert's Gtkdialog Tips thread to use gtkwialog -b mode.

I did it in a hurry so haven't checked if my converted versions will also all run on systems with dash as system shell - but most will; I think a couple might need a few more tweeks. Find them in post 4 of this thread here. Hopefully they will help you convert your own programs should you want to try running them on distributions that have dash or ash or bash as their system shell:

http://www.murga-linux.com/puppy/viewto ... 443#993443

I'm going to make a start converting some of my own programs now.

wiak

[fredx181]

Hi wiak, Just want to say (again) that you've done a great job, not only your discovery resulting in creating gtkwialog, but also the excellent documentation, examples, technical background, etc... etc... Hats Off !

One thing I wonder about, looking at your DebianDog/gtkwialog repository:
I see 7 commits from you containing change of Readme and some more, but are the differences for gtkwialog compared to original gtkdialog there ?

Fred

[wiak]

One thing I wonder about, looking at your DebianDog/gtkwialog repository:
I see 7 commits from you containing change of Readme and some more, but are the differences for gtkwialog compared to original gtkdialog there ?
pu
Fred

Not yet, Fred, been too busy and since considering minor code tweeks and not actually using github during my developments I'm not quite ready to push the source code there yet. But will happen soon enough. There is one particular area of code in gtkdialog I want to double-check how it works, just in case I've missed something, and also I want to convert a couple of my apps just as a double check. I've been converting precord, which has quite a lot of bash-related export code so a good test - haven't quite finished it yet. After that I'll push up the source code since it will be ready for proper testing and recompiling and pull requests and so on.

wiak

[wiak]

What an amazing job Thunor did of re-factoring the original gtkdialog code. I've been reading through some of it and the amount of work he did is far more enormous than any non-C programmer would imagine. It was far from just better implementing the Widgets to more closely match their inherent GtkDialog system capabilities. It would take a near obsession to learn the whole inner-workings of gtkdialog that Thunor obviously did.

My addition is simple, but is hopefully very useful for the very small effort I needed to expend implementing it. Most of my effort was simply background research to try find out why bash -f export didn't work well with gtkdialog - and looking at YAD code gave me the simple solution to that - just a small number of changes needed to gtkdialog itself over a very few files and thus with predictable results since nothing else needed to be touched (so far anyway... luckily).

Just a pity, I feel, that gtkdialog hadn't been written to use vbox and hbox constructions with simple curly bracket groupings (instead of pseudo xml tags) as used in IUP (with Lua and the other languages it supports), which is much nicer to program in (simpler, easier to read, supports comments, and harder to make mistakes in).

wiak

[wiak]

One, apparently rare, limitation found using gtkwialog on systems that do not use bash as the underlying system shell /bin/sh
(and legacy gtkdialog has that limitation anyway)

I spent one hour tonight converting Precord to use gtkwialog -b. That went fine and worked perfectly when underlying system shell was bash (which is no big deal since old version worked under legacy gtkdialog too with bash as system shell...).

But when I changed /bin/sh to be dash, the legacy gtkdialog version simply couldn't work at all because Precord is written in bash and uses a great many bash export -f functions. That being of course known and expected... But:

Though all the <action> contructs in the gtkwialog -b version of Precord can all find these functions, there is one other construct that happens to be used in current Precord that also calls up one of the bash functions and that is the <input> tag in one of the entry widgets (which calls bash function DateFile1). Unfortunately, none of the code I have added helps with that <input> tag situation, so that is a current limitation. Indeed, despite studying the code, I frankly do not yet know how <input> calls up exported functions - it is certainly not via the system() call.

I can only surmise, from the complex code involved, that it directly reads the function code from the shell environment, via perhaps a gtk library call, and then sends that function code to be processed via the mechanisms I have optionally modified. If so, legacy gtkdialog <input> command processing may expect a shell to interpret the function via system(), which does of course only work if underlying system shell is bash. So calling bash functions from <input> constructs certainly won't work with legacy gtkdialog.

Unfortunately, if my surmise turns out to be correct, then because the execution of that bash exported function requires an instance of bash to be running, which isn't the case with the gtkwialog -a or -b mod glib async or sync calls either (which don't call up any shell process) then that construct simply cannot work whichever mode is used when bash is not the underlying system shell. It is a small limitation, but one that has to be borne in mind.

In summary:

Though gtkwialog -b (or -a) mode can be used to convert many or even most legacy gtkdialog apps to work with dash, it does currently have at least this one newly found limitation:

you cannot call bash functions from <input> tags, only from <action> tags if underlying system shell is dash. There may be similar limitation; just remember -a and -b modes are specifically mainly related to <action>tag commandline_string opertion

I will have to therefore make a slight modification to Precord to workaround that remaining dash-related issue.

The easiest way around this for new programs is to never use exported bash functions in <input> tags.

Example of code that will not work when dash is the system shell:

Here is a simple exemplar program that will work using /bin/sh as bash but not when /bin/sh is dash, despite gtkwialog -b being used. Doesn't work with legacy gtkdialog either of course, when /bin/sh is dash:

Code: Select all

#! /bin/bash

hello (){
 echo "hello world"
}
export -f hello

export MAIN_DIALOG='
<vbox>
 <entry>
  <variable>ANYTHING</variable>
  <input>hello</input>
 </entry>
</vbox>
'

gtkwialog -b --program=MAIN_DIALOG

I'll write more on this limitation if I find more or any solution in code, but truthfully I think it probably has to be accepted as a limitation of both gtkdialog and gtkwialog. Fortunately, it is a limitation that can easy be avoided in the case of gtkwialog; not gtkdialog which cannot work at all with dash as system shell when bash exported functions being used anywhere.

Hopefully you understand what I'm talking about, but if not, just accept that as one limitation that has to be avoided if writing dash compatible apps in this manner.

I'm now looking through some other familiar bash/gtkdialog to see which will suffer from this limitation. I'll list any I've looked at here:

1. peasywifi, does not use <input> tags in the above manner so should convert nicely with gtkwialog -b for use with underneath dash shell (though its shebang would also need changed to #!/bin/bash for the exported functions to work.

2. My program cast2chrome should also convert nicely.

3. As fredx181 has I believe already proved, debdog-install (and xenialdog-install) should convert nicely (don't think these call exported functions anyway)

4. My program domyfile should convert nicely.

5. Despite being derived from Precord (albeit a long chain of ancestry) it looks like weX will convert nicely.

6. peasypdf should convert nicely (and probably most peasy apps).

7. ffconvert looks like it will convert okay.

Hmmm... I can't find any other problematic ones... only Precord... trust me to try to convert that first!

Quite a number of old Puppy util/apps don't use bash export -f at all, so they shouldn't generally need to be converted at all - just use gtkwialog in legacy mode (needs no switch for that).

Oh well, time will tell - I'll try converting cast2chrome next and come back to finish Precord later. If there is any particular app you'd like me to check (and maybe even convert), just let me know.

All going well with a couple of conversions in the next few days, I'll upload the source code to the DD organization github repository thereafter since I'm not planning any non-compatible changes if most basically converting fine.

wiak

[anikin]

wiak,

1. Can you, please have a look at the original mount-wizard script (see attachment). It is fred's mod of iguleder's script, that I brought to old DD. Will it work under dash? Unfortunately, It's been removed from the repos.

2. Please, also have a look at peasyglue - will it work with dash?

Thank you in advance,

[wiak]

I'll have a try tomorrow anikin cos its late night/morning here. I'm pretty sure peasyglue will work. Have to check out mount wizard.

Just got Precord running with dash as system shell underneath - first time I've had that on dash system, though did need slight tweak I mentioned in earlier post.

wiak

[fredx181]

Hi wiak, I had a look at pburn and it seems the only exported function is in /usr/local/pburn/box_tail and it has "tailing" exported to a <input>.... line
If you have time, can you have a look ?

Fred

[wiak]

@anikin: what is the issue with that mount-wizard with dash anyway. I can't see what existing problem would be at a glance. There are no export -f functions in it, which is main problem gtkwialog solves (allows bash exported functions). If its some kind of permission problem that would be a different matter altogether; please let me know.

peasyglue, on the other hand, needs gtkwialog -b, and I'll try that out - it should work then.

wiak

[wiak]

Hi wiak, I had a look at pburn and it seems the only exported function is in /usr/local/pburn/box_tail and it has "tailing" exported to a <input>.... line
If you have time, can you have a look ?

Fred

Yep, I'll add that to tomorrows list. If there is an <input> issue it can always be worked around as I managed with Precord.

EDIT: I see what you mean, in the while construct... tailing. Yes, that'll need a workaround I think. I'll try tomorrow later - can be done that's for sure.

wiak

[anikin]

@wiak

My bad, I must have panicked and confused myself and you. Mount-wizard does work with both dash and bash. Thank you for setting this straight!

[wiak]

Code: Select all

#! /bin/bash 
printf '
 #!/bin/bash
 echo "hello world"
' >/tmp/hello
chmod +x /tmp/hello


export MAIN_DIALOG=" 
<vbox> 
 <entry> 
  <variable>ANYTHING</variable> 
  <input>/tmp/hello</input> 
 </entry> 
</vbox> 
"

gtkwialog -b --program=MAIN_DIALOG

Or better maybe sometimes to use a HERE document instead of printf:

Code: Select all

cat >/tmp/hello <<'here_hello_function'
#! /bin/bash 
echo "hello world"
here_hello_function
chmod +x /tmp/hello

Single quoting the <<'here_hello_function' to turn off parameter substitution in the HERE document body.

The above is a workaround to the <input> bash exported function issue I posted a few posts back. There may be better ways, but above method worked well even with a big function.
It's the same methodology I employed with that one problem exported bash function in Precord. This is just a simple example but really the same method. In Precord the /tmp/file I created actually had two functions in it. Pretty simple when only one <input> with that issue. Pburn should work likewise I'd say.

wiak

[fredx181]

Hi wiak, I took on pfind to convert (I thought it should be less complicated than pburn)
It turned out to be a real challenge (for me anyway cos I'm a gtkdialog noob), replaced every instance of gtkdialog with "gtkwialog -b" in all related scripts (and sh symlinked to dash of course), but just doesn't work, the Search button does nothing.
I suspect at least some <action> or <input> lines are containing other bashism's than exported functions, but not sure.
I tried with this pfind:
https://fredx181.github.io/StretchDog/i ... .3_all.deb
(newer version than included in e.g. Xenialdog)

EDIT: I think I suspected right, e.g. this (in /usr/local/pfind/pfind):

Code: Select all

 <action>. '$PROGPATH'/func -search</action>

Should probably become something like this:

Code: Select all

 <action>bash -c ". '$PROGPATH'/func -search"</action>

EDIT2: There's checkbashisms (part of package "devscripts"), but unfortunately it doesn't work to check for bashisms inside <action>..</action>
https://linux.die.net/man/1/checkbashisms

Fred

[wiak]

I suspect at least some <action> or <input> lines are containing other bashism's than exported functions, but not sure.

Yes, that could be the issue you've come across. Of course if '<action>commandstrings' contain bashisms they are going to need bash -c (with gtkwialog -b mode) to interpret them), so not just for export -f cases, that's true.

But it's also the case that if an '<action>commandstring' requires a shell to do file expansion or job control, for example, either sh -c or bash -c will be required by gtkwialog in the -b mode (since that mode does not itself exec any shell automatically). The command mode -b glib mechanism does do UNIX style parsing, but:

Parses a command line into an argument vector, in much the same way the shell would, but without many of the expansions the shell would perform (variable expansion, globs, operators, filename expansion, etc. are not supported).

Hence '<action>commandstring' entries that need filename expansion or such need to include an appropriate (sh -c or bash -c) shell command at the front.

I'll add pfind to my list But this list may take a while to look at...

My own bash/gtkdialog programs (and most of rcrsn51's peasy scripts) do not contain that external file function method so will generally be easy to convert (since mainly just the export -f situation to deal with). Problem with the split file function method is that there are so many of them(!) so you have to grep the whole folder looking for suspects...

Then I generally load suspect files up in geany and use search/replace with search term <action> and replace term <action>bash -c " and 'carefully' use the Find button to take a look before I commit anything (and finish off by putting a " symbol at the end - though I sometimes adjust replace term with sh -c if bash -c not required) but hopefully I'll work out a more automatic convert method eventually... I also thereafter do a quick search through the <input> lines, though usually not many of these. Have you any quicker technique?

wiak

[wiak]

Are you sure that line you mention in pfind is actually a bashism. It does contain '.' (source in bash) so does need a shell. I'd think this is what is required for that line (including the double/single start/end quote syntax shown:

"'<action>sh -c ". '$PROGPATH'/func -search"</action>'"

If it's a bashism should be bash -c. Either way the shell command is needed at the front here to interpret the '.'

I note there are a few other <action> lines in pfind that contain that '.' at the beginning.

wiak

[wiak]

I did an ultra-quick /usr/local/pfind/pfind conversion attempt, which is attached. It partially works in dash (for example try searching from the Advanced button gui); this or some other component of pfind needs a bit extra debugging for perfection, but can't be far away...

If you don't have time or manage to debug it, I'll try some other time.

By the way, I found it useful to search and replace for this term also:

Code: Select all

&</action>

which needed a sh -c at the beginning too (for job control).

that end part of that action line being replaced with:

Code: Select all

&"</action>'"

and its front part replaced with:

Code: Select all

"'<action>sh -c "

Note that with these multi-function modularised shell/gtkdialog Puppy apps, I usually change to the relevant folder where they all are and do the likes of:

Code: Select all

grep '&</action>' *

and

Code: Select all

grep '<input>' *

and

Code: Select all

grep 'export -f' *

and finally, a more generic action tag search:

grep '<action[[:space:]]>' *

and similar...

to find in which files likely problems are. Then I open these up in geany for the actual search/replace style conversion. That part of the process is surprisingly quick once I've practiced it.

NOTE: pfind also needs usleep (though works without it), which isn't in XenialDog64 at least.

EDIT: /usr/local/pfind/pfilesearch/pfilesearch also needs a few fixes for conversion. I've also attached my converted version and that seems to fix things. Still some minor pfind bugs I see, but I think they are in the non-converted one anyway on XenialDog64, which is where the attached files are from. Need tested though and I'd advise a diff on the original and these converted ones to see exactly how I did it.

pfind was certainly not the easiest program to convert since quite a lot of sh -c commands are required in it, and the need to search multiple files to find the need - but easy once the method to do so is worked out.

EDIT: Still some debugging required - it is not forgetting the previous search result. Also, may need to try it first without the modified pfilesearch additon and using the Advanced buttons search first of all (then partially working with dash). Unless I get round to further debugging of course.

EDIT2: May have fixed the bulk of it. Was a bashism (case statement form I think in pfilesearch, so needed to amend pfind line 429 to:

"' <action>bash -c ". $PROGPATH/fu ... /action>'"

It is possible there are some other instances I've used sh -c when bash -c will be necessary. For speed of conversion I guess always easiest to use bash -c though who knows what trouble that may cause later!

EDIT3: Note that you get rid of the initial pfind grep error messages if you export a value for LANG before running the program. Generally not important. There are some other small error messages during running, but I think they are there whether using bash or dash (?). Program seems to work fine though.

EDIT4: Downloads deleted since I have since converted most recent pfind 6.3

wiak

[phat7]

How to execute gtkwialog_0.8.4_i386.deb.tar you linked on page 1?

[wiak]

How to execute gtkwialog_0.8.4_i386.deb.tar you linked on page 1?

You haven't given me sufficient information to answer you properly phat7, (but I'll do my best anyway). In particular, are you on a Debian-based system or a Puppy? - note that the file is a deb package (though I believe many pups can use that too).

After first removing the dummy (false) .tar extension you should install the package. The installation package manager will then put the gtkwialog executable file into /usr/bin, which is in your system's executable search PATH so will be found from then on. Just like with legacy gtkdialog, you use this to create new programs. Example scripts that should work with it automatically are given in post 4 of this thread; you need to copy the content of any one of these examples into a text file, give that text file a filename of your choice, and make it executable, from the commandline, with

Code: Select all

chmod +x your_chosen_filename

For example, once you correctly have gtkwialog installed in /usr/bin from the supplied deb package, you could try executing the following one of the post 4 example scripts:

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

From the directory you've stored the your_chosen_filename program, you run it with:

Code: Select all

./your_chosen_filename

If rox filemanager is not on your system, you could, say, change the rox & code line number 4 above to be pcmanfm &, or whatever filemanager your system has.

wiak

[wiak]

After the above success with pfind, I decided to have a go at pburn since it has a similar code organization. I regret that decision...

pburn is full of <action> lines of various sorts that need a shell added when trying to convert with gtkwialog -b mode. I believe there are also bashisms in some of these actions, so legacy gtkdialog won't work when underlying shell is dash.

I have had to give up on that one for now - tons and tons of code changes needed and what makes it harder is that it keeps changing from dialogs surrounded by double quotes to dialogs surrounded by single quotes, which require a different overall <action> quoting pattern...

And the <action></action> lines are all embedded in the middle of complex lines (rather than being separated to own lines).

A nightmare to convert.

Perhaps it would be easier to leave it in legacy gtkdialog mode (which is gtkwialog also with -a or -b option) and then modify some of the code to us dash ok rather than bash for the <action>commandlines. I haven't put head into that mode of thought yet, so I'm not sure if that is easy, easier, or likely. Has Slitaz not once used pburn? If so, and using busybox ash, they must have recoded some of it for legacy gtkdialog, but maybe I'm imagining I saw it in Slitaz (or somewhere else).

I may come back to it - but don't hold out hope for that...

I much prefer to convert the bash export -f using programs (such as my own and also some of the rcsrn51's peasy suite) - that's usually easy.

wiak

[wiak]

I've now published my first dash, ash, and bash system compatible app, 'cast2chrome' here:

http://www.murga-linux.com/puppy/viewto ... 012#991012

Depends on gtkwialog of course (running in -b mode).

wiak