Buttons do not regain focus after dialog dismissal.

I've noticed a funny thing about buttons under Linux.

(1) Use the mouse to click on a button that raises a dialog.
(2) Use the keyboard (TAB, ENTER, etc.) to dismiss the dialog. Do not
move the mouse.
(3) Once the dialog is dismissed, click the mouse again.
(4) Nothing happens.

Instead of (4), I would expect that the button would activate and the
same dialog would pop up.

This behavior can be seen in the wxPython demo:

wxPython Overview -> Common Dialogs -> MessageDialog

So, is this just a funny thing, or is this a bug?

Cheers,
C.D.

Hi,

I've used the Process.py demo as a starting point for an application that starts several processes, one after the other, and prints their output to an output window. On Linux, this logging seems to tremendously slow down the started process, pdflatex in my case (e.g. in comparison to starting pdflatex in a console). What might be the cause, and how could I circumvent this?
Process.py grabs the input stream of the running process and prints it to the output window like this:

        self.process = None
        self.Bind(wx.EVT_IDLE, self.OnIdle)

        self.Bind(wx.EVT_END_PROCESS, self.OnProcessEnded)

    def OnIdle(self, evt):
        if self.process is not None:
            stream = self.process.GetInputStream()
                   if stream.CanRead():
                text = stream.read()
                self.out.AppendText(text)

That might cause a lot of polling, because the OnIdle() handler is called whenever the app is not busy, won't it?

By the way... I don't recognise this when running the same script on Windows.

Thanks for any suggestions,

Nick.

Count Down wrote:

I've noticed a funny thing about buttons under Linux.

(1) Use the mouse to click on a button that raises a dialog.
(2) Use the keyboard (TAB, ENTER, etc.) to dismiss the dialog. Do not
move the mouse.
(3) Once the dialog is dismissed, click the mouse again.
(4) Nothing happens.

Instead of (4), I would expect that the button would activate and the
same dialog would pop up.

This behavior can be seen in the wxPython demo:

wxPython Overview -> Common Dialogs -> MessageDialog

So, is this just a funny thing, or is this a bug?

Please try a 2.5.4.1 preview. I think this may have been fixed.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Nikolas Arend wrote:

Hi,

I've used the Process.py demo as a starting point for an application that starts several processes, one after the other, and prints their output to an output window. On Linux, this logging seems to tremendously slow down the started process, pdflatex in my case (e.g. in comparison to starting pdflatex in a console). What might be the cause, and how could I circumvent this?

It's probably because the buffer used for the output of the process is filling up and so the pdflatex process is being put to sleep by the OS until there is room in the buffer again.

Process.py grabs the input stream of the running process and prints it to the output window like this:

       self.process = None
       self.Bind(wx.EVT_IDLE, self.OnIdle)

       self.Bind(wx.EVT_END_PROCESS, self.OnProcessEnded)

   def OnIdle(self, evt):
       if self.process is not None:
           stream = self.process.GetInputStream()
                 if stream.CanRead():
               text = stream.read()
               self.out.AppendText(text)

That might cause a lot of polling, because the OnIdle() handler is called whenever the app is not busy, won't it?

No, it is called when the the event queue *becomes* empty and won't be called again immediately unless you call event.RequestMore, in which case you will end up with a huge amount of polling. You might want to use a short duration timer instead.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin Dunn wrote:

Nikolas Arend wrote:

Hi,

I've used the Process.py demo as a starting point for an application that starts several processes, one after the other, and prints their output to an output window. On Linux, this logging seems to tremendously slow down the started process, pdflatex in my case (e.g. in comparison to starting pdflatex in a console). What might be the cause, and how could I circumvent this?

It's probably because the buffer used for the output of the process is filling up and so the pdflatex process is being put to sleep by the OS until there is room in the buffer again.

Process.py grabs the input stream of the running process and prints it to the output window like this:

       self.process = None
       self.Bind(wx.EVT_IDLE, self.OnIdle)

       self.Bind(wx.EVT_END_PROCESS, self.OnProcessEnded)

   def OnIdle(self, evt):
       if self.process is not None:
           stream = self.process.GetInputStream()
                 if stream.CanRead():
               text = stream.read()
               self.out.AppendText(text)

That might cause a lot of polling, because the OnIdle() handler is called whenever the app is not busy, won't it?

No, it is called when the the event queue *becomes* empty and won't be called again immediately unless you call event.RequestMore, in which case you will end up with a huge amount of polling. You might want to use a short duration timer instead.

Thanks for your explanations! I have a timer running anyway to check whether the process is still running (you suggested it, thanks again). Now I just put the

if self.process is not None:
           stream = self.process.GetInputStream()
           ...

stuff in the function that gets called by the timer. Is that pretty much what you meant? I experienced a perfermance improvement, but it's definitely not as fast as when I start pdflatex from a console.

Cheers, Nick.

Nikolas Arend wrote:

Robin Dunn wrote:

Nikolas Arend wrote:

Hi,

I've used the Process.py demo as a starting point for an application that starts several processes, one after the other, and prints their output to an output window. On Linux, this logging seems to tremendously slow down the started process, pdflatex in my case (e.g. in comparison to starting pdflatex in a console). What might be the cause, and how could I circumvent this?

It's probably because the buffer used for the output of the process is filling up and so the pdflatex process is being put to sleep by the OS until there is room in the buffer again.

Process.py grabs the input stream of the running process and prints it to the output window like this:

       self.process = None
       self.Bind(wx.EVT_IDLE, self.OnIdle)

       self.Bind(wx.EVT_END_PROCESS, self.OnProcessEnded)

   def OnIdle(self, evt):
       if self.process is not None:
           stream = self.process.GetInputStream()
                 if stream.CanRead():
               text = stream.read()
               self.out.AppendText(text)

That might cause a lot of polling, because the OnIdle() handler is called whenever the app is not busy, won't it?

No, it is called when the the event queue *becomes* empty and won't be called again immediately unless you call event.RequestMore, in which case you will end up with a huge amount of polling. You might want to use a short duration timer instead.

Thanks for your explanations! I have a timer running anyway to check whether the process is still running (you suggested it, thanks again). Now I just put the

if self.process is not None:
          stream = self.process.GetInputStream()
          ...

stuff in the function that gets called by the timer. Is that pretty much what you meant? I experienced a perfermance improvement, but it's definitely not as fast as when I start pdflatex from a console.

Python acutally uses the CPU quite excessively with the timer method. Wouldn't there be another way to redirect a processes output to a TextCtrl?

Cheers, Nick.