Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launch and Closewindow #16

Closed
GoogleCodeExporter opened this issue Apr 20, 2016 · 12 comments
Closed

Launch and Closewindow #16

GoogleCodeExporter opened this issue Apr 20, 2016 · 12 comments

Comments

@GoogleCodeExporter
Copy link

Launch and closewindow are bugged but they've been patched to work. This 
example illustrates the behaviour:

{{{
#!/bin/sh

GTKDIALOG=gtkdialog

export LAUNCHED_DIALOG='
    <window title="winClosewindow" resizable="false" margin="50">
        <button label="Closewindow">
            <variable>btnClosewindow</variable>
            <action>closewindow:btnClosewindow</action>
        </button>
        <variable>winClosewindow</variable>
        <action signal="hide">""</action>
    </window>'

export MAIN_DIALOG='
    <window title="winLaunch" resizable="false" margin="50">
        <vbox>
            <button label="Launch">
                <action>launch:LAUNCHED_DIALOG</action>
            </button>
            <button label="Closewindow">
                <action>closewindow:winClosewindow</action>
            </button>
        </vbox>
        <variable>winLaunch</variable>
        <action signal="hide">exit:Exit</action>
    </window>'

$GTKDIALOG --program=MAIN_DIALOG
}}}

You should be able to execute closewindow:LAUNCHED_DIALOG but instead any 
variable from the launched dialog has to be passed. Also, if you launch more 
than once then only the most recent will close. Any tidying-up of these 
functions will have to support the current behaviour for backwards 
compatibility.

I'm currently thinking about recording the program names on launch and maybe 
preventing duplicates from being launched. The application developer really 
should be creating unique program names if he wants to open duplicate dialogs.

Original issue reported on code.google.com by thunor...@hotmail.com on 28 Jul 2011 at 3:06

@GoogleCodeExporter
Copy link
Author

Hi thunor,

With the new development to fix this issue:

Are you still going to support the use of a launched dialog´s variable to be 
passed?.  For backward compatibility with programs already written to work like 
it.

Or a total functional rewrite is needed then breaking backward compatibility?

Regards,
clarf

Original comment by clarf.pu...@gmail.com on 28 Jul 2011 at 4:19

@GoogleCodeExporter
Copy link
Author

Hi clarf :)

Currently any variable from the launched dialog can be passed to closewindow, 
so I'm not going to change that functionality since everyone is using it. I 
will simply (or that's the plan) add an additional correct way to close the 
launched dialog.

Regards,
Thunor

Original comment by thunor...@hotmail.com on 28 Jul 2011 at 9:24

@GoogleCodeExporter
Copy link
Author

I'm working on something at the moment whereby I launch a dialog from a timer. 
it works the first time and then the timer stops functioning so it looks as 
though launching a dialog kills the timer. This would make sense since I have 
seen that launching requires exiting GTK+'s main loop and the GTK+ timer 
creation function apparently uses the main loop for timing.

I haven't investigated it yet; I just wanted to note it.

Original comment by thunor...@hotmail.com on 18 Nov 2011 at 1:54

@GoogleCodeExporter
Copy link
Author

The example I've given towards the top is wrong: it is supposed to be called 
without window tags i.e. it uses the second format of the window widget which 
is with the directives at the top and without window tags. I don't know why 
there's a second format -- maybe it was exclusively to support launched 
dialogs. Then the dialog works as expected (only one window will be opened) but 
then you can't use window tag attributes! The way around that is to use the 
window tag but maintain a value in a file that records the dialog launching and 
closing so you can check before launching another. There are benefits to using 
launch such as being able to refresh its widgets from the main dialog, but the 
system is messy and needs some attention.

Original comment by thunor...@hotmail.com on 18 Nov 2011 at 2:39

@GoogleCodeExporter
Copy link
Author

I discovered last night that a launch action terminates the list of actions so 
that any actions following it don't get executed. This also affects any 
triggering action e.g. a widget's action sets a value in a file and then the 
next action refreshes a target widget which reads this file and that triggers 
the target widget's default signal and one of the target widget's actions 
executes launch which terminates all further actions.

Original comment by thunor...@hotmail.com on 20 Nov 2011 at 10:27

@GoogleCodeExporter
Copy link
Author

Hello, is here any solution about this bug?
I downgrade to 0.7.20, because i wrote some scripts with 
      <button>
        <label>OK</label>
          <action type="closewindow">ABOUT</action>
      </button>
and if i click on OK, it will not closing in current version.

Thanks in advance
Daniel aka leiche 

Original comment by MeissS...@gmail.com on 16 Jul 2012 at 5:49

@GoogleCodeExporter
Copy link
Author

Hi Daniel

It does work, it's just that the way it has been implemented is problematic. 
Anyway, 0.8.0 has had a patch applied that fixes the even worse behaviour in 
0.7.20 so you shouldn't downgrade. Also there are working examples in the 
source package which you should look at, and I can't tell from your snippet of 
code why it fails to work. I'm guessing that your main window is using the 
<window> tag which you shouldn't have if you are planning on launching another 
window from it.

Regards,
Thunor

Original comment by thunor...@hotmail.com on 27 Jul 2012 at 11:33

@GoogleCodeExporter
Copy link
Author

In r326 I've gone through the launch and closewindow functions and added some 
code to display a warning if a launched window does not contain an equivalently 
named variable so that application developers will know if they've got it wrong.

I've added a new example example/miscellaneous/launch_and_closewindow which you 
should take a look at.

http://gtkdialog.googlecode.com/svn/trunk/examples/miscellaneous/launch_and_clos
ewindow

Regards,
Thunor


Original comment by thunor...@hotmail.com on 2 Aug 2012 at 4:44

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

I've experienced another problem although it's more a design limitation: 
attempting to launch a window from an <action 
signal="show">launch:mynewwindow</action> attached to the main window will 
cause an error coming from the parser making you think it's related to the main 
window, but the problem actually lies with parsing a program when one is 
already being parsed. After hours of debugging I found the line that causes 
this error -- automaton.c:515 gtk_widget_show_all() -- and it's pretty obvious 
now what the issue is: the run_program() function can only parse one program at 
a time i.e. it's not reentrant; in fact run_program() doesn't even return as it 
calls gtk_main().

I've just dealt with this by refusing to launch if instruction_counter != 0 
with a warning message sent to stderr.

Original comment by thunor...@hotmail.com on 28 Aug 2012 at 3:27

  • Changed state: New

@GoogleCodeExporter
Copy link
Author

What's remaining here then is the timer problem which I might be able to do 
something about; I'll come back to this.

Original comment by thunor...@hotmail.com on 29 Aug 2012 at 12:31

@GoogleCodeExporter
Copy link
Author

Original comment by thunor...@hotmail.com on 5 Sep 2012 at 4:34

  • Added labels: Priority-High
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

Fixed in r416.

The problem with the timer was quite simple: launching is a one way trip i.e. 
it doesn't return so doing it in a timer callback never returns to the callback 
-- I have added a check for this and a warning is dumped to the terminal. The 
solution is to get the timer to activate another widget that launches so that 
it's done outside of the callback.

There are no remaining issues with launch and closewindow so this is fixed.

Original comment by thunor...@hotmail.com on 8 Sep 2012 at 12:37

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant