TaskBarIcon problem with wxGTK 2.5.1
Gunnar Roth
It works as it should on windows. but using wxGTK 2.5.1 there is a
problem, If i close my app, now the app does not close completely.
The OnClose handler is executed, which does a Destroy() but the taskbar
icon goes a way for the moment and is then reinstalled somwhow and the
process does not end. if i use the any entry of the taskbar icon menu
now it segfaults.
can any kind soul, which has more experience with linux than me, tell me
what is going on?
regards,
gunnar
Vaclav Slavik
Gunnar Roth wrote:
> Hi i use a TaskBarIcon in my app (http://musik.berlios.de).
> It works as it should on windows. but using wxGTK 2.5.1 there is a
> problem, If i close my app, now the app does not close completely.
It's a bug in the wxTaskBarIcon implementation (it's still not
finished), if you could have a look at it and submit a patch, it
would help a lot. I have no idea how to do it (not yet, anyway). The
problem is that X11 implementation keeps a helper top level window
and wxGTK won't (correctly) exit as long as there is some top level
window.
But as a matter of fact, I think wxTaskBarIcon *should* behave the way
it works on X11. That is, the app should not exit if there's a task
bar icon and you should be required to destroy it explicitly. It's
quite stupid that you have to keep a hidden window around if you want
to write taskbar-only application. The question is, is fixing this
API worth breaking backward compatibility?
Regards,
Vaclav
--
PGP key: 0x465264C9, available from http://pgp.mit.edu/
Vadim Zeitlin
> But as a matter of fact, I think wxTaskBarIcon *should* behave the way
> it works on X11. That is, the app should not exit if there's a task
> bar icon and you should be required to destroy it explicitly. It's
> quite stupid that you have to keep a hidden window around if you want
> to write taskbar-only application. The question is, is fixing this
> API worth breaking backward compatibility?
I think it is. The other potentially interesting but too vague at the
moment idea I have is to have a wxDockedApp class which would have an
associated task bar icon and would manage the app shutdown correctly.
If this would be enough, we could avoid breaking the API.
Regards,
VZ
---------------------------------------------------------------------
Please read http://www.wxwindows.org/mlhowto.htm before posting.
To unsubscribe, e-mail: wx-users-u...@lists.wxwindows.org
For additional commands, e-mail: wx-use...@lists.wxwindows.org
Vaclav Slavik
Vadim Zeitlin wrote:
> I think it is. The other potentially interesting but too vague at
> the moment idea I have is to have a wxDockedApp class which would
> have an associated task bar icon and would manage the app shutdown
> correctly. If this would be enough, we could avoid breaking the
> API.
It would be a nice solution for taskbar-only apps, but less nice for
apps that have the icon only as optional part of the interface only,
I think. And it would still leave us with two implementations of
wxTaskBarIcon that behave differently, so from this point of view I
prefer to unify the behaviour.
Gunnar Roth
"Vadim Zeitlin" <va...@wxwindows.org> wrote in message
news:20040309095641.GJ8427@sunset...
> On Tue, Mar 09, 2004 at 10:25:51AM +0100, Vaclav Slavik wrote:
> > But as a matter of fact, I think wxTaskBarIcon *should* behave the way
> > it works on X11. That is, the app should not exit if there's a task
> > bar icon and you should be required to destroy it explicitly. It's
> > quite stupid that you have to keep a hidden window around if you want
> > to write taskbar-only application. The question is, is fixing this
> > API worth breaking backward compatibility?
>
> I think it is. The other potentially interesting but too vague at the
> moment idea I have is to have a wxDockedApp class which would have an
> associated task bar icon and would manage the app shutdown correctly.
> If this would be enough, we could avoid breaking the API.
so what is the correct way to use taskbar icon class? i have it embedded in
my app class.
how to destroy it? should i better create it with "new" and destroy it with
"delete"?
Or embbed in my mainframe window class?
why does the docs not mention the portability problems?
in windows it just works fine.
regards,
gunnar
Vaclav Slavik
Vadim Zeitlin wrote:
> VS> apps that have the icon only as optional part of the interface
> only, VS> I think. And it would still leave us with two
> implementations of VS> wxTaskBarIcon that behave differently, so
> from this point of view I VS> prefer to unify the behaviour.
>
> Me too. I still the idea of wxDockedApp class,
Me too...
> for only a subset of cases, but it's clearly less critical than
> fixing wxTaskBarIcon itself to behave identically on all platforms.
It's done now. wxMSW's wxTaskBarIcon was changed to behave in same way
as X11 version: you must destroy it when you destroy toplevel
windows, application with only taskbar icon left (but no
frames/dialogs) will *not* terminate as it used to.
This new behaviour is much easier to implement in X11 ports and it
makes it easier to write taskbar-only applications (you don't need to
keep a hidden wxFrame around anymore).
This is incompatible change that may affect some applications (in
particular, code that had wxTaskBarIcon instance as member of
wxApp-derived class will stop working), but the fix is easy: destroy
the icon yourself and do it *before* wxApp instance is destroyed.
Note that you can do that in 2.4, so it is still possible to have
same code that compiles & works with both branches.