Great intro.wiak wrote:I haven't studied your examples so not sure I understood your question
And to spare you the trouble of testing: gtkwialog -a mode does not work in this case.
I thought I tried that second option, but maybe I forgot to escape the quotes or something.MochiMoppel wrote: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>
Code: Select all
leafpad \</dev/null >/dev/null &
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.MochiMoppel wrote:Great intro.wiak wrote:I haven't studied your examples so not sure I understood your question
And to spare you the trouble of testing: gtkwialog -a mode does not work in this case.
@disciple:disciple wrote: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.
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"
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.MochiMoppel wrote:
BTW: Your question pups up from time to time (see here). Maybe zigbert should add the solution to his tips collection.
.
Yes.disciple wrote:t seems that if you use a fileselect action with either fs-action="file" or the deprecated accept="filename", it accepts either a file or folder. Would you see this as a bug?
Yes. If it doesn't your gtkdialog is broken.i.e. should it accept only a file?
Code: Select all
#! /bin/bash
export INPUT_FILE_DIALOG="
<window>
<vbox>
<text>
<label>What file shall we open?</label>
</text>
<hbox>
<entry fs-action=\"file\">
<variable>INPUTFILE</variable>
</entry>
<button>
<input file stock=\"gtk-open\"></input>
<action type=\"fileselect\">INPUTFILE</action>
</button>
</hbox>
</vbox>
</window>
"
INPUTFILEGUI="`gtkdialog --program=INPUT_FILE_DIALOG`"
Yes.disciple wrote:OK, so does this work as expected for you?
It may not be obvious that OK opens a folder so that you can continue to find a file, but it wouldn't close the dialog as the mission to select a file is not completed. The important thing is that, when selecting a file, "OK" closes the dialog and enters the returned file name into the entry field. What would you expect? That "OK" is grayed out when clicking on a folder?I didn't expect to be able to select a folder and click OK.
That's actually what I expected as it is standard gtk behaviour, but here it instead closes the dialog and enters the returned folder name into the entry field.MochiMoppel wrote:It may not be obvious that OK opens a folder so that you can continue to find a file
@disciple: No, something must be broken on your system. Only enters a file here (same with gtkwialog by the way: only accepts a file).disciple wrote:Sorry, I wasn't clear enough.That's actually what I expected as it is standard gtk behaviour, but here it instead closes the dialog and enters the returned folder name into the entry field.MochiMoppel wrote:It may not be obvious that OK opens a folder so that you can continue to find a file
Ah ha! A serial troll and a 'friend' of Mochi's, I should have known. Reminder to myself: ignore troll mfbmfb wrote:Flash has just banned Forum member, rufwoof, on the basis of a single incident. If musher0 cannot reform and become reasonable - I can expand upon musher0's deception above and provide Flash, at least, with many more major reasons why he, musher0, should get the same treatment.
...
My thanks to MochiMoppel (the author of this "viewer") for his helpful answer in the post immediately above and also for this entire project.
...
He will win who has military capacity and is not interfered with by the sovereign [Flash].
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. [I know musher0 so very well, whereas musher0 does not even begin to know me].
As far as I can tell the answer is to read OUTPUTFILE from an input file, that way you can add an action to write to the input file and another action to refresh the variable. I suppose that is relatively straightforward, but personally I'm averse to writing files just for things like this.disciple wrote: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:
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?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>
It seems the solution doesn't work if I try to use it with xdg-open i.e.disciple wrote: what is the most straightforward way to open up a program and not have it block what the rest of your script does?
Code: Select all
<action>xdg-open http://www.murga-linux.com/puppy/viewtopic.php?p=149208#149208 >/dev/null &</action>
Code: Select all
xdg-open: unexpected argument '>/dev/null'