GtkDialog - tips

[wiak]

forking seems rather gratuitous.

Whoa!!! Now wait a minute! Whilst you suggest its adoption as a development of gtkdialog itself, that statement above is like accusation of theft. This is not avconv versus ffmpeg (!!!) and there were justified reasons for the decision (for now) to fork: basically the very many legacy gtkdialog applications, which would all need to be modified if, as rcsrn52 basically pointed out to me, would need to be modified if my simple but fundamental core change to gtkdialog was adopted in gtkdialog itself.

Others could have contributed to the discussion, or involved themselves in the discussion that already took place if they had wished. Fact is, as I earlier states, I was just trying this for my own interests and possible needs and with no intention of forcing something into gtkdialog itself, since that would have serious consequencies for the existing shell/gtkdialog legacy app developers (in terms of having to modify their code, when they understandably wouldn't want forced to do so). The following is just an extract:

I understand the issue. I was involved in the discussion when it arose several years ago.

But gtkdialog is a mission-critical piece of software. Before people start tinkering with it, I would like to understand the rationale.

I didn't manage to get my desired change to work anyway.

So patching the gtkdialog binary is now off the table?

I doubt if it was ever on the table for most people. I was just wanting a patched version for my own interest really and still do, if only to understand why gtkdialog doesn't accept bash -c "commandstring" (in <action> tags) as way of 'seeing' the export -f bash functions, when /bin/sh is dash Of course, were an improvement possible to gtkdialog without upsetting the apple cart more generally that would surely be good. I remember BarryK didn't seem to trust Thunor's first attempts to mod gtkdialog, but that is all water under the bridge now.

...

So "gtkwialog" could be added to Fred's repo as a separate item?

Then people who want to build new apps using it can do so, without worrying about side-effects on older gtkdialog apps.

Or people could gradually upgrade their gtkdialog apps to gtkwialog after proper testing.

Yes, that will be possible.

Gtkwialog operates somewhat differently in one core/fundamental way to legacy gtkdialog, which can result in some if not all existing bash/gtkdialog scripts needing several modifications to use it
...
Being a fork with diverged functionality gtkwialog has been given a different code name hence users can choose to use either legacy gtkdialog or this new gtkwialog as they see fit. People who have legacy shell/gtkdialog apps , who do not wish to modify them, will want to continue using legacy gtkdialog. In time it may or may not diverge further.

Frankly, if there is to be that kind of comment/suggestion of being 'gratuitous' then simply best I stop doing this development altogether; no harm done, let others develop how they will. You may not have meant what your comment implies, but comments like that at the very top take away from actual development work time and just throw spanners in works, sorry.

EDIT: By the way, there is also an issue, that gtkwialog may evolve further, which means its operation may end up differing even more from gtkdialog; I have previously stated that I my intention was to keep changes to the minimum because I want the interface to be as familiar to developers as possible (to make it easier for them to use it if they wish), but with the changes made there are some little extras that follow on naturally in my own wishes. Actually, one of my considerations was to try and better accommodate legacy applications, not to protect legacy gtkdialog, nor to threaten its core position in Puppy Linux, but simply to make app porting to the likes of Pristine Debian simpler for developers (and, particularly, simpler for myself). Gratuitous? No.
Anyway, for anyone at all who does disapprove of what has taken place, not much has taken place at all - consider it an experiment then that can be forgotten.

[wiak]

By the way, prior to realising the changes would upset legacy apps, and prior to having worked out exactly (albeit providing a detailed plan/code idea) how to do what I wanted anyway, I wrote the following in this very thread:

NOTE: Yes, maybe I could implement this gtkdialog improvement easily enough usually, but I broke ribs and punctured lung, so cannot think as clearly as usual like alone being able to spend much time compiling/debugging in front of a computer... Later I suppose, but I wish someone else would implement this apparently very simple but much needed improvement. Maybe jlist/woodenshoe-wi or 01micko since they are used to modifying/compiling this code anyway???! Maybe someone could at least try it and test it to see how it goes?

There was no subterfuge involved in this 'experiment' at all.

You can 'have [a] discussion' with whoever you like; that has nothing to do with me. You jump the gun Sir.

Meanwhile, I will be getting back to my coding, for my own purposes only; the current mods I'm doing being in fact to make the product better support legacy apps despite my 'tinkering'.

[disciple]

forking seems rather gratuitous.

Whoa!!! Now wait a minute! Whilst you suggest its adoption as a development of gtkdialog itself, that statement above is like accusation of theft

Sorry, but I didn't mean it like that at all.

This is not avconv versus ffmpeg (!!!)

No, it is different in many ways. One of them is that upstream gtkdialog isn't under active development, so you're not even competing with the original developer or anything.

and there were justified reasons for the decision (for now) to fork: basically the very many legacy gtkdialog applications, which would all need to be modified if, as rcsrn52 basically pointed out to me, would need to be modified if my simple but fundamental core change to gtkdialog was adopted in gtkdialog itself.

Sure, I'm essentially saying I don't think that is a good reason to fork (long-term). If other people think it is, then great - I'm not saying I'm right.

Others could have contributed to the discussion, or involved themselves in it, that already took place if they had wished.

That's what I was trying to do. I assumed it wasn't a discussion that was over and done with, since you said you have made it a fork "for now".

Fact is, as I earlier states, I was just trying this for my own interests and possible needs and with no intention of forcing something into gtkdialog itself, since that would have serious consequencies for the existing shell/gtkdialog app developers.

It sounded like the consequences were fairly minimal - have I missed something?

Your changes seem like they make gtkdialog behave much more sensibly.
Please keep up the good work if you can.

[wiak]

Okay, I'll wait see what the people who are described as on the Puppy Team themselves say about all of this (if anything). Despite you saying your own intentions were not meant to be taken the way they came across to me, I am sure there are some who agree with you in the sense of meaning exactly the attack it seemed to me (I accept you didn't intend that) - so it is probably good you brought it up. The BarryK (I presume) designated Puppy Team have been silent thus far, which is fine either way since I'm not in their team anyway. I am longterm user of Puppy and developed many a little app on it but have not hidden the fact I tend to now used Dogs more. I guess that might be unsettling for some, who from some comments would not touch a Dog with a bargepole! Strange idea to me - it is here on the Forum - I can't help but think there are many who use Dogs now and again, or maybe often, but don't dare to admit it. Sad life.

I prefer just to get on with my code now, personally if nothing else, anyway, whichever way that discussion goes.

wiak

EDITED

[disciple]

http://puppylinux.com/team.html

Puppy Linux team is you!
...
Puppy Linux Team works on do-ocracy principle.
...
If you’re good at coding, help to improve various programs used in Puppy Linux.

[deleted whilst disciple has his discussion with 01micko]

It's hard to discuss while it's deleted, isn't it?
But gtkdialog isn't under active development, doesn't have a current homepage, and is long abandoned by the original author, so there's no way your work could seriously be considered a malicious fork.

[wiak]

http://puppylinux.com/team.html

Puppy Linux team is you!
...
Puppy Linux Team works on do-ocracy principle.
...
If you’re good at coding, help to improve various programs used in Puppy Linux.

[deleted whilst disciple has his discussion with 01micko]

It's hard to discuss while it's deleted, isn't it?

Not at all. The discussion concerning the prealpha and even the earlier design is well-documented now on the forum.

But gtkdialog isn't under active development, doesn't have a current homepage, and is long abandoned by the original author, so there's no way your work could seriously be considered a malicious fork.

Actually, I think you are being unfair to jlist/woodenshoe-wi saying that; though he admits his addition was minor, having mainly been done earlier by Thonor, it is only a short while ago that he updated Thunor's GTK3 additions.

Like I said, the reason I worked on this development was purely for my own interest without thinking about whether I was beholden to the designated Puppy Team or not or whether they would assume the right to have 'discussions' regarding what I could do or not. Of course, it did cross my mind to be careful to try and not upset anyone by this work; I do see a moral correctness in publishing openly and letting those with an interest to speak on the matter if they so decide, but waiting for permission to code was never in my mind of course. Though I am aware the project was abandoned by its original developer I am also aware that Puppy Team people (particularly 01micko forked it, but basically took ownership of it, and the longtime never seen Thunor did tons of work on it. Taking over custodianship of gtkdialog may or may not have been with official backing of the original developer though I imagine it probably was).

wiak

[wiak]

It would also, be inappropriate for me to leave the prealpha testing download links in place (which I considered incomplete and not for any 'official' release), when it is obvious there may now be some discussion regarding the legitimacy (morally, justifiably, or otherwise) of the project (particularly in terms of it being forked/renamed).
EDIT: I'm not talking about legal concerns of course - the license allows forking, but not always morally or justifiable to do so - that is true.
Note that my concerns are not so much with your comments above disciple but I know the way this forum sometimes work, in terms of the way some people go crazy negative with discussion on matters like this.
EDIT: to a very large extent I want to keep out of such discussions, which in real terms I see as having nothing to do with my aims and work. Regarding your own original comments, like I said, I accept I took them in a way that was not your intention. However, I think you should read over your words in the sense that your talk of you having discussion with 01micko about my work, smacks of some kind of in cliche Puppy Team authoritarianism, is dubious to me, to say the least.
EDIT2: I'm not saying that there is such a thing as Puppy Team authoritarianism, by the way; not from 01micko's position or voice anyway - I know he has stated his belief that Puppy is a do-ocracy, but their are some of the 'Puppy faithful' who have stronger attitudes that verge on control IMO. Despite gtkdialog being a core Puppy app, gtkdialog is not Puppy.

Stewards are not democratically elected. They are instead appointed by the existing stewards based on the revered do-ocracy principle.

EDIT: @disciple: It does strike me, reading that Puppy Team page, that none of the designated Stewards are people I've ever seen active on any of the Dog threads, yet it is stated that the Dogs are accepted as under the Puppy umbrella - would seem to me that a bit of representation might be a good thing, even if just for collaborative reasons. But maybe not. Don't worry about gtkwialog development, by the way, it's ongoing - only on download release in temporary suspension in case anyone has any actual complaint or demand about any aspect of the fork.

By the way, in 'doing' this project or any other, I do not mean I dream of becoming a Puppy 'Steward' of any sort; I woudn't want a responsible role like that ever - I like being a free agent to openly work on Puppy or Dogs or Tiny Core Linux or Slitaz and so on.

[wiak]

[deleted whilst disciple has his discussion with 01micko]

It's hard to discuss while it's deleted, isn't it?

Point taken, my comment was too harsh and I have now amended it. Nevertheless, I have decided to at least temporarily suspend/delete the prealpha downloads links posted, since I think you have brought up something that some others may feel a need to discuss amongst themselves so I hope they do that now and get it over with. I'm not saying I won't publish later anyway (and realise you yourself do want it published as a non-fork), but for the moment I'll just continue my development work at home and let others voice their opinions without having to worry that my prealpha program is an assault of some sort or an official release in any way.

EDIT: On second thoughts, I've changed my mind. I'm re-instating the pre-alpha download links. Whether the fork/rename is considered acceptable to some is irrelevant to me. I feel it would be remiss of me to deny anyone on the forum to chance to try this out while it seems to be stable and work as intended. It is still only released for testers, with the usual caveats, and not in any way an official publication - hence the version: prealpha...
I changed my mind also, partly because I notices that TazPup has reverted to using /bin/sh -> busybox ash, and gtkwialog might prove very useful there in getting legacy Puppy gtkdialog apps to work.

Having said that I do hope anyone who does object to gtkwialog has their discussion now and finish that.

wiak

[mistfire]

@wiak has a point about gtkdialog issue. It is hard to port puppy applications to other distro using the current gtkdialog scripts without modifying it. gtkdialog does not follow what interpreter is using in a script which is crucial in my TazPup. If sh -> bash then the installer.cgi of tazpanel doesnt work and puppy apps work. If sh -> busybox then the situation was reversed. installer.cgi works but puppy applications does not work because it cant call exported function even #!/bin/bash was set.

I hope that someone found the best solution to fix this issue.

[wiak]

to fix this issue.

The way I'll be modifying my own apps such that they run on either bash or dash or busybox ash system shells is here:

http://www.murga-linux.com/puppy/viewto ... 434#993434

An alternative is to simply re-write the legacy shell/gtkdialog app to not use bash export -f functionname. However, since lots of apps (certainly all of mine) do use export -f, I prefer to modify them using gtkwialog though currently that is just being developed/tested in what I've designated as prealpha status. I haven't made any official release; just provided download link of the prealpha binary in case anyone wanted to test it. Works and seems stable though.

A few tips on using gtkwialog are given here:

http://www.murga-linux.com/puppy/viewto ... 437#993437

But overall, there has not been much practice at doing such app conversions so tips and few at the moment.

wiak

[disciple]

Hi again wiak, thanks for putting your work back online.

One more clarification, continuing from the other thread. (EDIT - sorry, no, posted here accidentally - that should teach me for posting from a phone!)

your talk of you having discussion with 01micko about my work

Sorry, when you said something about me having a discussion with Micko, I thought it was just because you were wound up - I didn't realise you actually thought that was what I was intending to do.
I was just trying to say that if Micko's repository is considered to be the gtkdialog "upstream", it would be good for you to do a pull request against it, or talk to him about whether he would be open to it.
I didn't mean to suggest that I should talk to Micko.

[wiak]

No problem disciple.

As maintainer of Puppy Linux I am sure 01micko is well aware of developments taking place in open view on murga forum and if he or any other of the Puppy Stewart's wanted to comment or make contributions to the gtkwialog developments which have now taken place I'm sure they would have done so.

In the same way that mpv is a fork of mplayer2 which is a fork of mplayer, as I said, I believe it is better to have this fork under a non-confusing name.

As with mplayer/mplayer2 most of the code is from the earlier base - only a new, preferred couple of operation modes have been added, but legacy gtkdialog mode is absolutely not recommended for future app developments if using gtkwialog. That is a fundamental difference between the two.

Since your first comment I have in fact carefully re-organised the code such that the original legacy gtkdialog mode will continue to operate without any change (for example, gtkdialog can be a symbolic link to gtkwialog and all legacy apps will work same as before). However, there is substantial core functionality difference in the intended new core mode I recommend gtkwialog be used in (option [-b]) - and that's an important recommendation in order to avoid the longtime issues programmers have had with legacy gtkdialog in terms of its compatibility with bash and non-bash system shells, particularly when using export -f functionality provided by bash.

To still publish the revamped program 'gtkdialog' (in other words just to push it to 01micko's Puppy fork, would hide the fact that gtkdialog legacy mode is not recommened by me in writing this program and the same old incompatible programs situation would continue in new programs should any bash programmer still use that legacy gtkdialog mode, which I forcibly am trying to discourage so newer apps will run compatible on other Linux systems without having to insist on /bin/sh being forced to be a symlink to bash (a horrendous situation IMO).

In other words, whilst legacy gtkdialog mode is included (and would be the active default mode) that situation (which I'm not at all really happy with being default mode) is for the sake of backwards compatibility only. Indeed the subtle codename change is important in my opinion (and wish) in order to highlight the difference. Legacy mode is there, but gtkwialog is 'not' legacy gtkdialog.

I also think this is a good opportunity to 'change the name' from the more-than-a-little confusing 'Gtkdialog', when 'GtkDialog' is already used as the name of the Gtk library system, which legacy Gtkdialog simple gui builder uses to achieve its functionality. Some people, as I've said, thus think Gtkdialog and GtkDialog are the same thing, and included by default with Gtk, which is not correct.

I would, however, be happy to consider Gtkwialog being primarily hosted on Puppy Linux (01micko site) in replacement/alternative to the legacy Gtkdialog currently there (rather than pushed into it) - that would certainly save me having to worry about its future maintenance. But I am easy on this matter and am fine hosted Gtkwialog on my own github site anyway.

However, like I've said already, the Puppy Linux Team, who have that own clone of original gtkdialog, and it is their clone on which I based my development of gtkwialog, have remained silent and not contributed even in the forum discussions about my developments. I am sure 01micko is busy on more important matters, but the Puppy Steward's team is large enough some comment no doubt would have been given if they had any interest in the work. Some of these Puppy Stewards are, afterall, considered gtkdialog experts and had plenty to say when Thunor was making his contributions. But times change and people's interests maybe move on, so that is up to them and I have no issues with them on these matters either way.

I certainly see no point in legacy gtkdialog and new gtkwialog both being installed on the same distribution. That would be unnecessary duplication since gtkwialog does in fact contains all of current legacy gtkdialog functionality anyway. However, it is entirely up to Puppy, and similarly for the Dogs, what they want to use on their distribution and I am not pushing anyone about that one way or the other.

All the source code files remain with top notice Copyright (C) László Pere <pipas@linux.pte.hu> since that is the original developer of most of the system. Other continuation contributors are also fully acknowledged as per the sources on Puppy gtkdialog legacy github site. I believe there is no infringement of any license conditions or rights - people will be able to use or not use gtkwialog as they wish once it is officially published.

Like any code being developed, if I find that people have an interest in it in the sense that it is actively being used then that is enough incentive for me to maintain, develop and publish it. If there is no such active use happening then the development and publication has no importance other than for my own use.

wiak

[01micko]

Hi wiak, disciple et al

I have been following this development from the sidelines.

First and foremost, I do not consider myself in any way the maintainer of gtkdialog. I was considering to add mavrothal's patches for mac but decided against for various reasons. I should add a patch such that those who want to compile it on a mac can do so easily. I allowed woodenshoe-wi's pull request because he has been working with gtk3 and considered that his patches don't affect the gtk2 functionality.

The reason I created the repo is that google code was shutting down and feared the code may have been lost. Many others forked the code on github and possibly other repositories with similar thoughts.

I have created a new branch of gtkdialog called gtkwialog. https://github.com/01micko/gtkdialog/tree/gtkwialog

I don't know that this is the correct approach, but it is there. Pull requests welcome.

[wiak]

Hi wiak, disciple et al

I have been following this development from the sidelines.

First and foremost, I do not consider myself in any way the maintainer of gtkdialog. I was considering to add mavrothal's patches for mac but decided against for various reasons. I should add a patch such that those who want to compile it on a mac can do so easily. I allowed woodenshoe-wi's pull request because he has been working with gtk3 and considered that his patches don't affect the gtk2 functionality.

The reason I created the repo is that google code was shutting down and feared the code may have been lost. Many others forked the code on github and possibly other repositories with similar thoughts.

I have created a new branch of gtkdialog called gtkwialog. https://github.com/01micko/gtkdialog/tree/gtkwialog

I don't know that this is the correct approach, but it is there. Pull requests welcome.

Thankyou for posting 01micko. I will consider the matter further. From what I have already said I'm sure you realise that I do not favour gtkwialog being merged into legacy gtkdialog (which is what happens when a branch of gtkdialog). As I said, I believe gtkdialog suffers from confusing naming, and hence took this opportunity to avoid my fork being also confused with GtkDialog Gtk library system. As I also said, I certainly would consider gtkwialog being hosted as a separate fully alternative to gtkdialog - though the vast majority current code base is identical the intended operation 'mode' is entirely new and different in gtkwialog. Yes, my recent code changes that allow legacy gtkdialog mode would allow it to be merged back in easily but I myself do not like that approach currently.

wiak

[disciple]

Hi guys,
Back totally on topic, I came across this series and found it rather useful. It doesn't seem to have been mentioned here yet.
gtkdialog Exploration – articles and examples – series introduction

I also have a couple of questions I was wondering if anybody has a quick answer to:

1. Using the fileselect action, it is possible to make the file chooser open to a particular folder by using fs-folder something like this:

Code: Select all

    <entry accept=\"savefilename\"
           fs-filters-mime=\"application/pdf\"
           fs-folder="'$HOME'" 
           fs-title=\"Select output file\"> 
     <variable>OUTPUTFILE</variable> 
     <input>echo '$OUTPUTFILE'</input>
    </entry> 
    <button> 
     <input file stock=\"gtk-new\"></input> 
     <action type=\"fileselect\">OUTPUTFILE</action> 
    </button> 

But what I'd really like to do is make the file chooser open to show the current selection. i.e. click the button, choose a file, then later click the button again and have it open in the location of the same file (rather than at a set location i.e. fs-folder, or in the list of recent items, which is default). Is this possible to achieve in a relatively straightforward way?

2. Using either "legacy" gtkdialog, or gtkwialog's new modes, what is the most straightforward way to open up a program and not have it block what the rest of your script does?
i.e. to use a button to open a help page in a browser or something, without blocking anything else in your program.
If I use something like `defaultbrowser &`, then it is backgrounded, so I can continue to use my gtkdialog gui, but my script is supposed to do stuff once I close the gui, and it doesn't - it waits until the browser has also been closed.
I tried* various combinations using `disown` and `bash -c` and `nohup` etc, but couldn't get anything to work - all that stuff seems to be a bit too confusing for me!

*EDIT - if it matters for this, my testing was not in puppy, so /bin/sh is not bash, and defaultbrowser is a symlink to arora, which is not running until it is launched from my gui.

[wiak]

@01micko: Sorry, disciple posted his next comment following on to the above onto the more appropriate Gtkwialog Development thread and I replied there to disciple and more generally to yourself, not realising it was a different thread.

To save time, my replies were:

http://www.murga-linux.com/puppy/viewto ... 777#993777

http://www.murga-linux.com/puppy/viewto ... 779#993779

wiak

[disciple]

2. Using either "legacy" gtkdialog, or gtkwialog's new modes, what is the most straightforward way to open up a program and not have it block what the rest of your script does?
i.e. to use a button to open a help page in a browser or something, without blocking anything else in your program.
If I use something like `defaultbrowser &`, then it is backgrounded, so I can continue to use my gtkdialog gui, but my script is supposed to do stuff once I close the gui, and it doesn't - it waits until the browser has also been closed.
I tried* various combinations using `disown` and `bash -c` and `nohup` etc, but couldn't get anything to work - all that stuff seems to be a bit too confusing for me!

*EDIT - if it matters for this, my testing was not in puppy, so /bin/sh is not bash, and defaultbrowser is a symlink to arora, which is not running until it is launched from my gui.

I see that this is only a problem if assigning the output of the gtkdialog command to a variable. i.e. watch the echoed output in this example and you'll see that it only waits for leafpad to be closed in the first case:

Code: Select all

#!/bin/sh 

export HELP_DIALOG=" 
<window> 
<vbox>
  <button>
   <label>Open leafpad</label>
   <action>leafpad &</action> 
  </button> 
  <button ok>
  </button>
</vbox> 
</window> 
" 

MAINGUI="`gtkdialog -p HELP_DIALOG`"

echo "hello"

gtkdialog -p HELP_DIALOG

echo "goodbye"

exit 0

I *think* this actually makes sense, but I expected to be able to solve it by instead using `nohup leafpad &`. I was wrong.
I wondered if nohup was somehow broken in my environment, but a simple test away from gtkdialog shows it is working.

[disciple]

Removing gtkdialog to simplify the problem:

Code: Select all

MAINGUI=`echo goodbye & nohup leafpad`; echo $MAINGUI

I was on the wrong track with nohup. This is the solution:

Code: Select all

MAINGUI=`echo hello & leafpad </dev/null &>/dev/null &`; echo $MAINGUI

Trying to apply that method for a gtkdialog action I get errors like this:

Code: Select all

sh: 1: </dev/null: not found
sh: 1: >/dev/null: not found

or

Code: Select all

bash: </dev/null: No such file or directory
bash: >/dev/null: No such file or directory

So maybe the answer is to just to avoid calling gtkdialog in that way.

[MochiMoppel]

So maybe the answer is to just to avoid calling gtkdialog in that way.

Never give up

This works for me:

Code: Select all

#!/bin/sh
export HELP_DIALOG=" 
<window> 
<vbox> 
<button> 
<label>Open leafpad</label> 
<action>leafpad >/dev/null &</action> 
</button> 
<button ok> 
</button> 
</vbox> 
</window> 
"
MAINGUI=$(gtkdialog -p HELP_DIALOG) 
echo "$MAINGUI"

Your code, though a bit "overengineered" and bash specific, would also work but needs surrounding quotes:

Code: Select all

<action>"leafpad </dev/null &>/dev/null &"</action>

BTW: Your question pups up from time to time (see here). Maybe zigbert should add the solution to his tips collection.


.

[wiak]

2. Using either "legacy" gtkdialog, or gtkwialog's new modes, what is the most straightforward way to open up a program and not have it block what the rest of your script does?

I haven't studied your examples so not sure I understood your question as you intend it, but in gtkwialog -a mode, you can use a button to open another app and get immediate return to the dialog gui with, for example:

Code: Select all

<action>leafpad</action>

No extra shell is used here so no shell-job-related '&' required; leafpad is simply fork/exec'd so runs independently of the dialog thereafter, so any end stuff your dialog would need to do is not effected by leafpad thus running in its own process.

Note though that -a mode may not always be useful though since you can't 'mix' -b and -a modes of gtkwialog at the same time (not in this version anyway... that matter along with simple IPC facility is what I'm thinking about for a testing branch). -b mode more closely resembles legacy gtkdialog behaviour in that action commands are waited for prior to return to the dialogue. It differs from legacy gtkdialog in that no action /bin/sh -c at all is used by default - that's up to the programmer if he/she wants it. Advantage of that is instead of /bin/sh -c, the programmer can use bash -c, which is why gtkwialog is compatible with bash export -f functions syntax even when the underlying shell is dash or ash. But for your question, gtkwialog -a is the short and most efficient mode (assuming I understood your question).

wiak