GtkDialog - tips

[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

[MochiMoppel]

I haven't studied your examples so not sure I understood your question

Great intro.

And to spare you the trouble of testing: gtkwialog -a mode does not work in this case.

[disciple]

Great, thanks.

This works for me:
...

Code: Select all

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

...
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>

...

I thought I tried that second option, but maybe I forgot to escape the quotes or something.

Ah, this also works. The trouble I had was that I thought I needed to escape the > as well as the <

Code: Select all

leafpad \</dev/null >/dev/null &

[wiak]

I haven't studied your examples so not sure I understood your question

Great intro.

And to spare you the trouble of testing: gtkwialog -a mode does not work in this case.

Ok, forget it. I was answering disciple's question re: gtkwialog with what I thought he meant. Your sarcasm is unnecessary and out of place and not worthy of further comment or regard.

wiak

[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.e. to use a button to open a help page in a browser or something, without blocking anything else in your program.

@disciple:

I wonder if you would mind explaining to me how the following I suggested does not fit what you were asking (you can put >/dev/null after leafpad of course if you additionally wish):

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=$(gtkwialog -a -p HELP_DIALOG)
echo "$MAINGUI"

Note that, as I said, no & is required with mode -a (and this method does not require the running of /bin/sh -c, which legacy gtkdialog answer does whether you like it or not).

wiak

[wiak]

Okay, I follow the issue you had now disciple - I had read it only on Mochi's answer, which turned out to have missed out the last few lines of your script so didn't see the problem.

Interesting example. Useful for me to know in case I can fine tune what I'm compiling.

Doesn't excuse the ridiculous sarcasm I had to suffer though, but that's another issue and I've taken note.

Thanks, wiak

[disciple]

(wrote this while you were posting)

Don't echo MAINGUI. Echo some other text.

1. Run the script.
2. Click the button to open leafpad.
3. Click OK. The text is not echoed yet. We want it to be.
4. Close leafpad. The text is echoed now.

[disciple]

Yes, it would be very nifty if you could make it possible to achieve this along with what you were posting about in the other thread about non-blocking backgrounded actions in the blocking mode.

[wiak]

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

The given solution as a tips pattern is useful to know but even better for some would be a detailed explanation of what caused the problem in the first case and exactly in terms of processes, subshells, tty connections, or whatever why this solution works. I do not know the answer to what causes this issue, which may or may not be obvious, but I admit to often finding solutions like these by brute force trial and error rather than by technical accuracy/understanding. However, when trying to program improvements into gtkdialog it really is necessary to exactly understand what went on rather than just blindly accepting a method/solution, so if anyone knows that answer (and not just some googled pseudo answer) would be better than just a tip for zigbert's collection.

Proper understanding is better than a list of tips/patterns (useful thought these are) but I have searched on the forum and whilst the problem has been posted before, and solution similarly provided, no correct explanation has been forthcoming. And of course there is a real properly explainable technical explanation to why the issue occurs.

The construct $() uses a subshell to start a program/process so that seems to be part of the issue.

The >/dev/null proves necessary, but I don't know what it does here that fixes things. Using <action>leafpad 1>&- &</action> is slightly more efficient than using <action>leafpad >/dev/null &</action> in this case by the way (since no filename lookup involved), which may or may not be a clue to the overall operation.

I suspect that since gtkdialog is being started in a subshell then the action command leafpad somehow not having its stdin and stdout connected to appropriate open file descriptor though I haven't however been able as yet to work out the detailis, or if what I'm imagining is the true issue, so if anyone knows the exact correct mechanism that would be a better solution aid.

wiak

[wiak]

.

[rcrsn51]

This was interesting. I have seen situations where a sub-process of a gtkdialog app "leaked" data into stdout, which eventually came back out through the main $(gtkdialog).

This required some extra processing at the end to clean up the desired output from $(gtkdialog).