gtkdialog problem: child window not opening consistently
I had borked my gtkdialog3. I uninstalled the version that caused the problem and reinstalled the version with the patch by Patriot that fixes closing of a child dialog window from the child or from the main program.
I also found the correct syntax to use closewindow in a program as per HOWTO-gtkdialog-tips.
As to the other problem with the launch of ABOUT_DIALOG, I will try to investigate that further. Maybe do a run with the debug option and see if anything surfaces.
I may use that code line in a small gtkdialog3 script and see if the bug still surfaces.
I also found the correct syntax to use closewindow in a program as per HOWTO-gtkdialog-tips.
As to the other problem with the launch of ABOUT_DIALOG, I will try to investigate that further. Maybe do a run with the debug option and see if anything surfaces.
I may use that code line in a small gtkdialog3 script and see if the bug still surfaces.
I did that too.
Compare mine that was broken into separate lines for ease of reading code to yours.
It is attached.
Notice that I added a line <variable>ABOUT_DIALOG</variable>
Placement of that is important!
I also changed <action type="/closewindow"/>ABOUT_DIALOG</action>
to <action type="closewindow">ABOUT_DIALOG</action>.
A suggestion is to NOT make the ABOUT_DIALOG one line.
It is easier to check for errors if it is broken up as I did.
Sorry for no indentation. I was in a hurry.
It worked fine in the small script that has two CHILD processes.
Compare mine that was broken into separate lines for ease of reading code to yours.
It is attached.
Notice that I added a line <variable>ABOUT_DIALOG</variable>
Placement of that is important!
I also changed <action type="/closewindow"/>ABOUT_DIALOG</action>
to <action type="closewindow">ABOUT_DIALOG</action>.
A suggestion is to NOT make the ABOUT_DIALOG one line.
It is easier to check for errors if it is broken up as I did.
Sorry for no indentation. I was in a hurry.
It worked fine in the small script that has two CHILD processes.
- Attachments
-
- snap_about_dialog.tar.gz
- My test script.
- (934 Bytes) Downloaded 689 times
gktdialog ships with some example code, and one of them illustrates launching a child dialog. The code is essentially the same. I think that some gtkdialog feature I am using in snap2 (such as notebook, checkbox, etc.) is triggering the glitch. I ought to investigate further, but I am packaging up a new snap2 version. The new version has the main dialog close during backup, to draw the user's attention to the xterm window where the backup is happening. I also made compressed logfiles optional and made the names mirror.log and snapshot.log. Thanks for your feeback, 8-bit!
I wonder if the changing of MAIN_DIALOG is confusing the call.
I had noticed that you changed it conditionally for various actions to be done by your program.
Also, have you tried putting a For Statements in MAIN_DIALOG etc in the short test script to see what happens or make a dummy conditional MAIN_DIALOG change in the short test script to see if that is what is affecting the launch call.
I had noticed that you changed it conditionally for various actions to be done by your program.
Also, have you tried putting a For Statements in MAIN_DIALOG etc in the short test script to see what happens or make a dummy conditional MAIN_DIALOG change in the short test script to see if that is what is affecting the launch call.
I certainly don't think my recycling of the MAIN_DIALOG variable has anything to do with this, since each invocation of gtkdialog is entirely new and unrelated to previous invocations. However, I think I did already try avoiding re-use of MAIN_DIALOG, and got the same results...
I guess I could take a copy of snap2 and start cutting out portions of it step by step, until the 'About' dialog button starts to work. I'll do that later since I am busy with other things now.
I guess I could take a copy of snap2 and start cutting out portions of it step by step, until the 'About' dialog button starts to work. I'll do that later since I am busy with other things now.
Yes, but the idea is to open a child window, leaving the main program window open, rather than terminating the main window in order to put up a new dialog. Use of xdialog would require terminating the gtkdialog window, I believe.
As it turns out, my workaround to this problem is to have a 'Help' on the main gtkdialog which terminates the gtkdialog and put up a new one to show program help, loaded from a file. In windows other than the main gtkdialog, the 'About' button works, and I'm using it.
In sum, I think I have a satisfactory workaround for my 'About' button. However, I would like to be able to launch warning boxes from the main program window without closing the window.
As it turns out, my workaround to this problem is to have a 'Help' on the main gtkdialog which terminates the gtkdialog and put up a new one to show program help, loaded from a file. In windows other than the main gtkdialog, the 'About' button works, and I'm using it.
In sum, I think I have a satisfactory workaround for my 'About' button. However, I would like to be able to launch warning boxes from the main program window without closing the window.
You can easily use Xdialog without terminating the main window. I use it in Pwireless2 for all my child windows.
Code: Select all
<button>
<label>foo</label>
<action>/this/script/can/do/anything/you/want/it/to.sh</action>
</button>
Good point, thanks! I was trying to avoid more than one file for snap2, to have it simply install in /usr/local/bin/. I should consider a new install structure with multiple supporting files.
Executing a distinct script as you suggest, I could of course also just use a new instance of gtkdialog, rather than xdialog. I would probably choose that option, since I am targeting Debian systems also and I want to avoid adding dependencies unnecessarily (xdialog is not standard on Debian the way it is on Puppy).
Executing a distinct script as you suggest, I could of course also just use a new instance of gtkdialog, rather than xdialog. I would probably choose that option, since I am targeting Debian systems also and I want to avoid adding dependencies unnecessarily (xdialog is not standard on Debian the way it is on Puppy).