toasterbox lines?

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

Thanks,
Che

Hi Che,

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 24 August 2010 18:15, C M wrote:

Are you using a timer for triggering each step of the animation or is it blocking until the animation is completed? Since the toast is just a wx.Frame then if the main loop is not blocked then the other windows in the application should automatically get paint events to refresh their damaged areas.

···

On 8/24/10 10:37 AM, Andrea Gavana wrote:

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh).

--
Robin Dunn
Software Craftsman

Hi Robin,

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh).

Are you using a timer for triggering each step of the animation or is it
blocking until the animation is completed? Since the toast is just a
wx.Frame then if the main loop is not blocked then the other windows in the
application should automatically get paint events to refresh their damaged
areas.

No, I'm not using a timer... the code does something like this:

        for i in xrange(something):
            self.SetDimensions(self._dialogtop[0], dimY,
                               self.GetSize().GetWidth(), windowsize)

            wx.Usleep(self._sleeptime)
            self.Refresh()

I can't see any refreshing problem on Windows 7, but I can on XP.
Maybe adding a wx.(Safe)Yield can fix it? I'll try tomorrow, otherwise
I'll have to rewrite the loop inside a timer event handler.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 24 August 2010 22:48, Robin Dunn wrote:

On 8/24/10 10:37 AM, Andrea Gavana wrote:

Thanks for the explanation, Andrea. I have no idea what to recommend;
maybe what Robin mentioned will do the trick. Thanks for looking into
it.

Che

···

On Tue, Aug 24, 2010 at 1:37 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Hi Che,

On 24 August 2010 18:15, C M wrote:

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

Hi Che,

Hi Che,

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

Thanks for the explanation, Andrea. I have no idea what to recommend;
maybe what Robin mentioned will do the trick. Thanks for looking into
it.

I think I might have fixed it, the updated version is in SVN. Could
you please try it and see if it works?

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 25 August 2010 20:11, C M wrote:

On Tue, Aug 24, 2010 at 1:37 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 24 August 2010 18:15, C M wrote:

Yielding there does not do well on the Mac, it appears that the yield is delaying much longer (processing more pending events) before returning than on Windows. See http://dl.dropbox.com/u/727255/Snap002.mov

It's possible that even a Windows box could have this issue if the machine is busy at the same time. Doing each step of the animation in a timer event will likely be much more smooth and stable, although you may still want to do something like check how long it has been since the last step was done and skip a step if it's been too long.

···

On 8/25/10 1:12 PM, Andrea Gavana wrote:

Hi Che,

On 25 August 2010 20:11, C M wrote:

On Tue, Aug 24, 2010 at 1:37 PM, Andrea Gavana<andrea.gavana@gmail.com> wrote:

Hi Che,

On 24 August 2010 18:15, C M wrote:

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

Thanks for the explanation, Andrea. I have no idea what to recommend;
maybe what Robin mentioned will do the trick. Thanks for looking into
it.

I think I might have fixed it, the updated version is in SVN. Could
you please try it and see if it works?

--
Robin Dunn
Software Craftsman

Yes, I see, it doesn't look good on the Mac :frowning: . I'll try to refactor
things using a timer instead. Good to have someone testing things on
the Mac though :slight_smile: . Maybe one day, when I'll be rich enough, I'll
buy one for myself just to play with wxPython on another platform :-).

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 25 August 2010 23:44, Robin Dunn wrote:

On 8/25/10 1:12 PM, Andrea Gavana wrote:

Hi Che,

On 25 August 2010 20:11, C M wrote:

On Tue, Aug 24, 2010 at 1:37 PM, Andrea Gavana<andrea.gavana@gmail.com> >>> wrote:

Hi Che,

On 24 August 2010 18:15, C M wrote:

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

Thanks for the explanation, Andrea. I have no idea what to recommend;
maybe what Robin mentioned will do the trick. Thanks for looking into
it.

I think I might have fixed it, the updated version is in SVN. Could
you please try it and see if it works?

Yielding there does not do well on the Mac, it appears that the yield is
delaying much longer (processing more pending events) before returning than
on Windows. See http://dl.dropbox.com/u/727255/Snap002.mov

It's possible that even a Windows box could have this issue if the machine
is busy at the same time. Doing each step of the animation in a timer event
will likely be much more smooth and stable, although you may still want to
do something like check how long it has been since the last step was done
and skip a step if it's been too long.

Hi Andrea. I just tried the updated version on Windows XP and it
looks good! Unfortunately I also read that it is not looking too good
on Mac. (When you get enough money for a Mac, could you try to get a
little extra and pick up one for me, too? :smiley: )

Maybe the timer solution will work? Good luck.

Che

···

On Wed, Aug 25, 2010 at 4:12 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Hi Che,

On 25 August 2010 20:11, C M wrote:

On Tue, Aug 24, 2010 at 1:37 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Hi Che,

On 24 August 2010 18:15, C M wrote:

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

Thanks for the explanation, Andrea. I have no idea what to recommend;
maybe what Robin mentioned will do the trick. Thanks for looking into
it.

I think I might have fixed it, the updated version is in SVN. Could
you please try it and see if it works?

Andrea.

<apple-spokesman-mode>
A Mac mini is not hugely expensive and makes a good development machine if there is not a whole lot else running on it. The mini I got several years ago is still being used for occasional testing and also for building the release binaries, and has been a very dependable little machine. The specs for the current minis look *very* nice, but I bet you could find a used one for 2/3 the cost or less and still have one that is as good or better than mine.
</apple-spokesman-mode>

:slight_smile:

···

On 8/25/10 1:50 PM, Andrea Gavana wrote:

Maybe one day, when I'll be rich enough, I'll
buy one for myself just to play with wxPython on another platform :-).

--
Robin Dunn
Software Craftsman

Hi Che & All,

Hi Che,

Hi Che,

I was considering using ToasterBox (gotten from AGW through svn) as a
notification method (instead of wxMessageDialogs, which require
interaction...as per Kevin Ollivier's suggestion) and noticed a rather
minor visual glitch that I'd thought I'd mention.

On my screen (XP, wxPython 2.8.10, Python 2.5), when the TB closes,
there are a number of horizontal lines drawn over the window that is
sitting behind the TB. This is seen in the demo. If you maximize the
demo and run the TB, the lines will appear on the grey bar of the demo
that says "Demo log messages". Using it in an app I have, the effect
is more pronounced, since the lines occur all down the height of the
TB on the window behind it.

I'm not familiar with toasterboxes generally, but I imagine these
lines ought not to be there and do add visual noise that is not
desirable. I don't mean to be picky and don't know if it is a
difficult fix, Andrea, but I thought I'd just mention it.

The issue stems from the fact that, when ToasterBox "scrolls" down
(i.e., it's closing down), I set its dimensions (in terms of widget
height, in pixels) and Refresh() it. However, for the widgets *behind*
the ToasterBox (your main panel, or other widgets) their screen area
becomes damaged (i.e., it needs a refresh). I did not put a call to
Refresh() for the widgets which may be behind the ToasterBox, as it is
not always cheap to refresh a window, and a priori ToasterBox knows
nothing about what kind of widget lives behind it. It could be a cheap
half-empty panel (so no harm in a Refresh() of that), but it could
also be a complex animated 3D VTK scene through OpenGL. And that is
less cheap to Refresh() :slight_smile:

Anyway, there might be other solutions for that: I'll try and see if
the Refresh() thing solves the issue, but I am open to all suggestion
on how to properly redraw the damaged area of the widgets behind TB.

Andrea.

Thanks for the explanation, Andrea. I have no idea what to recommend;
maybe what Robin mentioned will do the trick. Thanks for looking into
it.

I think I might have fixed it, the updated version is in SVN. Could
you please try it and see if it works?

Andrea.

Hi Andrea. I just tried the updated version on Windows XP and it
looks good! Unfortunately I also read that it is not looking too good
on Mac. (When you get enough money for a Mac, could you try to get a
little extra and pick up one for me, too? :smiley: )

Maybe the timer solution will work? Good luck.

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 26 August 2010 00:10, C M wrote:

On Wed, Aug 25, 2010 at 4:12 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 25 August 2010 20:11, C M wrote:

On Tue, Aug 24, 2010 at 1:37 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 24 August 2010 18:15, C M wrote:

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent method works for TLWs for Windows, Mac and also on GTK if there is a compositing window manager is running. I've banged out some changes that switch it to using SetTransparent instead of pywin32, see the attached patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and repeatedly drawing the text over itself looks muddy when anti-alias font support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box stacked up that there is the same animation problem when they slide down, so it could use the same timer treatment.

toasterbox.patch (11 KB)

···

On 8/26/10 12:14 PM, Andrea Gavana wrote:

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

--
Robin Dunn
Software Craftsman

Hi Robin,

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent
method works for TLWs for Windows, Mac and also on GTK if there is a
compositing window manager is running. I've banged out some changes that
switch it to using SetTransparent instead of pywin32, see the attached
patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and
repeatedly drawing the text over itself looks muddy when anti-alias font
support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box
stacked up that there is the same animation problem when they slide down, so
it could use the same timer treatment.

Thank you so much for the patch. I have applied a slightly modified
version of it (wxPython 2.8.X.Y doesn't have the attribute
wx.BG_STYLE_PAINT, so I used wx.BG_STYLE_CUSTOM) and I have
implemented the multiple ToasterBoxes sliding in/out using a timer.
Any feedback would be more than welcome.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 27 August 2010 07:06, Robin Dunn wrote:

On 8/26/10 12:14 PM, Andrea Gavana wrote:

Andrea, on XP I tried it and it looks smooth/no lines--but if I set it
to a backgroundcolour the toast is that color only when not moving;
when moving, it is white.

(Btw, on this note, in the docs, the method name is wrongly given as
SetPopupBackgroundColor when it is actually SetPopupBackgroundColour).

Thanks again,
Che

···

On Fri, Aug 27, 2010 at 5:16 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Hi Robin,

On 27 August 2010 07:06, Robin Dunn wrote:

On 8/26/10 12:14 PM, Andrea Gavana wrote:

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent
method works for TLWs for Windows, Mac and also on GTK if there is a
compositing window manager is running. I've banged out some changes that
switch it to using SetTransparent instead of pywin32, see the attached
patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and
repeatedly drawing the text over itself looks muddy when anti-alias font
support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box
stacked up that there is the same animation problem when they slide down, so
it could use the same timer treatment.

Thank you so much for the patch. I have applied a slightly modified
version of it (wxPython 2.8.X.Y doesn't have the attribute
wx.BG_STYLE_PAINT, so I used wx.BG_STYLE_CUSTOM) and I have
implemented the multiple ToasterBoxes sliding in/out using a timer.
Any feedback would be more than welcome.

Andrea, on XP I tried it and it looks smooth/no lines--but if I set it
to a backgroundcolour the toast is that color only when not moving;
when moving, it is white.

(Btw, on this note, in the docs, the method name is wrongly given as
SetPopupBackgroundColor when it is actually SetPopupBackgroundColour).

Thanks again,
Che

I should specify: wxPython 2.8.10.1 / Python 2.5 / WinXPsp2.

Hi Che,

Hi Robin,

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent
method works for TLWs for Windows, Mac and also on GTK if there is a
compositing window manager is running. I've banged out some changes that
switch it to using SetTransparent instead of pywin32, see the attached
patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and
repeatedly drawing the text over itself looks muddy when anti-alias font
support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box
stacked up that there is the same animation problem when they slide down, so
it could use the same timer treatment.

Thank you so much for the patch. I have applied a slightly modified
version of it (wxPython 2.8.X.Y doesn't have the attribute
wx.BG_STYLE_PAINT, so I used wx.BG_STYLE_CUSTOM) and I have
implemented the multiple ToasterBoxes sliding in/out using a timer.
Any feedback would be more than welcome.

Andrea, on XP I tried it and it looks smooth/no lines--but if I set it
to a backgroundcolour the toast is that color only when not moving;
when moving, it is white.

Can you try with the latest SVN? I just updated it.

(Btw, on this note, in the docs, the method name is wrongly given as
SetPopupBackgroundColor when it is actually SetPopupBackgroundColour).

Which docs? The one on my website:

http://xoomer.virgilio.it/infinity77/AGW_Docs/toasterbox.ToasterBox.html#toasterbox.ToasterBox.SetPopupBackgroundColour

seems to have the correct description.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 28 August 2010 01:07, C M wrote:

On Fri, Aug 27, 2010 at 5:16 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 27 August 2010 07:06, Robin Dunn wrote:

On 8/26/10 12:14 PM, Andrea Gavana wrote:

Hi Che,

Hi Robin,

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent
method works for TLWs for Windows, Mac and also on GTK if there is a
compositing window manager is running. I've banged out some changes that
switch it to using SetTransparent instead of pywin32, see the attached
patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and
repeatedly drawing the text over itself looks muddy when anti-alias font
support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box
stacked up that there is the same animation problem when they slide down, so
it could use the same timer treatment.

Thank you so much for the patch. I have applied a slightly modified
version of it (wxPython 2.8.X.Y doesn't have the attribute
wx.BG_STYLE_PAINT, so I used wx.BG_STYLE_CUSTOM) and I have
implemented the multiple ToasterBoxes sliding in/out using a timer.
Any feedback would be more than welcome.

Andrea, on XP I tried it and it looks smooth/no lines--but if I set it
to a backgroundcolour the toast is that color only when not moving;
when moving, it is white.

Can you try with the latest SVN? I just updated it.

Hi Andrea. Same issue as before, it seems. Maybe I'm doing something
wrong? The way I am setting the color is through this code:

tb = TB.ToasterBox(self)
tb.SetPopupBackgroundColour('light blue')
tb.SetPopupText('Some text')
tb.Play()

(Btw, on this note, in the docs, the method name is wrongly given as
SetPopupBackgroundColor when it is actually SetPopupBackgroundColour).

Which docs? The one on my website:

http://xoomer.virgilio.it/infinity77/AGW_Docs/toasterbox.ToasterBox.html#toasterbox.ToasterBox.SetPopupBackgroundColour

seems to have the correct description.

That one does, yes. I saw the error on the wxPython site docs:
http://www.wxpython.org/docs/api/wx.lib.agw.toasterbox.ToasterBox-class.html

Thanks,
Che

···

On Fri, Aug 27, 2010 at 6:44 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 28 August 2010 01:07, C M wrote:

On Fri, Aug 27, 2010 at 5:16 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 27 August 2010 07:06, Robin Dunn wrote:

On 8/26/10 12:14 PM, Andrea Gavana wrote:

Hi Che,

Hi Che,

Hi Robin,

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent
method works for TLWs for Windows, Mac and also on GTK if there is a
compositing window manager is running. I've banged out some changes that
switch it to using SetTransparent instead of pywin32, see the attached
patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and
repeatedly drawing the text over itself looks muddy when anti-alias font
support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box
stacked up that there is the same animation problem when they slide down, so
it could use the same timer treatment.

Thank you so much for the patch. I have applied a slightly modified
version of it (wxPython 2.8.X.Y doesn't have the attribute
wx.BG_STYLE_PAINT, so I used wx.BG_STYLE_CUSTOM) and I have
implemented the multiple ToasterBoxes sliding in/out using a timer.
Any feedback would be more than welcome.

Andrea, on XP I tried it and it looks smooth/no lines--but if I set it
to a backgroundcolour the toast is that color only when not moving;
when moving, it is white.

Can you try with the latest SVN? I just updated it.

Hi Andrea. Same issue as before, it seems. Maybe I'm doing something
wrong? The way I am setting the color is through this code:

tb = TB.ToasterBox(self)
tb.SetPopupBackgroundColour('light blue')
tb.SetPopupText('Some text')
tb.Play()

Apologies, I thought you were using wx.Colour instances. Fixed now in
SVN (hopefully) to handle named colours as well.

(Btw, on this note, in the docs, the method name is wrongly given as
SetPopupBackgroundColor when it is actually SetPopupBackgroundColour).

Which docs? The one on my website:

http://xoomer.virgilio.it/infinity77/AGW_Docs/toasterbox.ToasterBox.html#toasterbox.ToasterBox.SetPopupBackgroundColour

seems to have the correct description.

That one does, yes. I saw the error on the wxPython site docs:
wxPython API Documentation — wxPython Phoenix 4.2.2 documentation

I know, these ones are not up to speed wrt the AGW ones :slight_smile:

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==

···

On 28 August 2010 01:56, C M wrote:

On Fri, Aug 27, 2010 at 6:44 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 28 August 2010 01:07, C M wrote:

On Fri, Aug 27, 2010 at 5:16 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 27 August 2010 07:06, Robin Dunn wrote:

On 8/26/10 12:14 PM, Andrea Gavana wrote:

Hi Che,

Hi Che,

Hi Robin,

Should be fixed now in SVN. I also implemented the scrolling style
TB_SCR_TYPE_FADE: with this style, ToasterBox will fade in/out instead
of scrolling up/down (Windows only, requires Mark Hammond's pywin32
package). I'd be happy to receive feedback if this version works or
not for you.

Pywin32 is not needed for making transparent TLWs. wx.Window.SetTransparent
method works for TLWs for Windows, Mac and also on GTK if there is a
compositing window manager is running. I've banged out some changes that
switch it to using SetTransparent instead of pywin32, see the attached
patch. You may want to clean it up a bit because it was a rush job.

I also changed how the painting is done because there was some flicker, and
repeatedly drawing the text over itself looks muddy when anti-alias font
support is turned on. I changed a few other things along the way as well.

I just noticed as I was typing this that when there are more than one box
stacked up that there is the same animation problem when they slide down, so
it could use the same timer treatment.

Thank you so much for the patch. I have applied a slightly modified
version of it (wxPython 2.8.X.Y doesn't have the attribute
wx.BG_STYLE_PAINT, so I used wx.BG_STYLE_CUSTOM) and I have
implemented the multiple ToasterBoxes sliding in/out using a timer.
Any feedback would be more than welcome.

Andrea, on XP I tried it and it looks smooth/no lines--but if I set it
to a backgroundcolour the toast is that color only when not moving;
when moving, it is white.

Can you try with the latest SVN? I just updated it.

Hi Andrea. Same issue as before, it seems. Maybe I'm doing something
wrong? The way I am setting the color is through this code:

tb = TB.ToasterBox(self)
tb.SetPopupBackgroundColour('light blue')
tb.SetPopupText('Some text')
tb.Play()

Apologies, I thought you were using wx.Colour instances. Fixed now in
SVN (hopefully) to handle named colours as well.

Andrea, thanks, I tried it again and it worked very well. I also
tried out the fading style and that looks quite nice. I'll see if I
can test on Linux later tonight. Hopefully Mac is fine. Thanks again
so much for all this work. I'm looking forward to moving away from
having users hit "OK" so often to simply notify them of little
changes, and this strikes me as the way to go.

That one does, yes. I saw the error on the wxPython site docs:
wxPython API Documentation — wxPython Phoenix 4.2.2 documentation

I know, these ones are not up to speed wrt the AGW ones :slight_smile:

By the way, those docs you did look great!

Che

···

On Fri, Aug 27, 2010 at 7:06 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 28 August 2010 01:56, C M wrote:

On Fri, Aug 27, 2010 at 6:44 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 28 August 2010 01:07, C M wrote:

On Fri, Aug 27, 2010 at 5:16 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

On 27 August 2010 07:06, Robin Dunn wrote:

On 8/26/10 12:14 PM, Andrea Gavana wrote: