GtkDialog - tips

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

[disciple]

Hi guys, another question:
It 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? i.e. should it accept only a file? Or is there a trick to make it accept only a file?

[MochiMoppel]

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.

i.e. should it accept only a file?

Yes. If it doesn't your gtkdialog is broken.
Not sure what you mean by "it" and "accept". You may select a file or folder but the widget will only return a file, never a folder.

[disciple]

OK, so does this work as expected for you?

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`"

I didn't expect to be able to select a folder and click OK.

[MochiMoppel]

OK, so does this work as expected for you?

Yes.

I didn't expect to be able to select a folder and click OK.

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?

[disciple]

Sorry, I wasn't clear enough.

It may not be obvious that OK opens a folder so that you can continue to find a file

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.

[wiak]

Sorry, I wasn't clear enough.

It may not be obvious that OK opens a folder so that you can continue to find a file

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.

@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]

Ah, it looks like the problem might be only when selecting a directory in the "recently used" list, and at least some other gtk (2 and 3) programs are also affected. Leafpad is the only one I tried that isn't.

[wiak]

Pity I got myself locked out of my Gtkwialog development thread. I was just a bit mad for a moment - which may be unacceptable to some purists, but I make no claim of purity. So there I was, gathering my thoughts again, and preparing to remove my abandoned notice - what a surprise to find I could not do that! Anyway, what the hell - it was all a bit of fun from my perspective and really been wanting to stop working on any project for a couple of years now.

And who was that mfb?!!! Oh my goodness, what an awful person! Throw away his keys too! Never heard of him or her before, truly.

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

Ah ha! A serial troll and a 'friend' of Mochi's, I should have known. Reminder to myself: ignore troll mfb

Good luck Mochi, the program code you dropped on me in that gtkwialog dev thread does not work for dash (I had tried it of course and knew that) but, well done, it does indeed work with busybox ash, and truly that is surprising. Don't know if gtkdialog -p will work with bash exported functions - that one I really haven't since bothered to try. And good luck rcsrn51 (I always get these letters mixed up - but I'm not dyslexic - I just can't get the order of them right in my head) - I'm glad you liked my tip, but of course you would know how to do that anyway.

As for my poor locked thread - oh dear, Flash, you ballsd that one up for me good and proper - may be truly abandoned now - bad timing - unnecessary sudden moderation - what on earth did you do that for? Don't answer - it doesn't matter. I am not upset in any way at all - I am not 0musher or saintless, though maybe they were never actually upset either - it is hard to take the serious types seriously (and I'm not now referring to 0musher or saintless)... In Scotland, we just don't think like that. But yeah, lock my thread - throw the keys away - wasn't about to change the world in any way, anyway.

I will work things out via Fredx181's Dog team eventually I'm sure. Even though rcsrn51 has set up camp there now too - oh my goodness, what a drama! Great news is that my lovely wife returns from her business trip in a few days time and my kids are equally excited about that - oh wow, I'm a lucky guy, if only you knew... If she had only not been away I might have avoided getting into that gtkdialog sacred ground mess altogether but her absence just inspired me (especially since, as I said, I was somewhat invalided) to code relentlessly for a while. That period of madness was thus about to end at least anyway - ah, Scotland, what a place - best country in the world really and our bite is just a joke usually - unless you are English of course.

I've been accused of drinking vodka in my locked out comment thread. Hahaha - funny guy. Bit over-the-top serious for me too though. Obviously interested in coding nevertheless and I'm sorry if he was disappointed I got mad for these moments - I was only a wee bit mad anyway - just enough to bark (I forgot I didn't have a key back to my thread). For me, admittedly, and being Scottish I do hate admitting any kind of truth, it is all but a game on here - but some really tiring attitudes I do have to say - I suppose it is a kind of social forum for some too - me too a little but uses too much family time for that and should limit such chat. But some no doubt think exactly the same of me (in terms of tiring - do you know what a Glasgow handshake is??? - just joking) - but if you ever use one of my programs just remember: that's the price you pay, free as in vodka.

And don't greedily jump in thinking you've won something that would be freely given anyway - wait till you have all the keys needed to unlock the safe first. Don't jump the gun; timing is everything, and sometimes life is like a game of chess - be wise rather than authoritarian, which is bad enough in 'real' life.

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?

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]

Hi guys, coming back to this question:

what is the most straightforward way to open up a program and not have it block what the rest of your script does?

It seems the solution doesn't work if I try to use it with xdg-open i.e.

Code: Select all

<action>xdg-open http://www.murga-linux.com/puppy/viewtopic.php?p=149208#149208 >/dev/null &</action>

It produces an error:

Code: Select all

xdg-open: unexpected argument '>/dev/null'

Any ideas how to avoid this?

Thanks.