Re: [Libreoffice] [PATCH] Use GtkStatusIcon instead of libegg

Hi, Michael,

On Mon, Dec 06, 2010 at 03:59:17PM +0000, Michael Meeks wrote:
> Hi David,
>
> On Mon, 2010-12-06 at 15:18 +0100, David Tardon wrote:
> > On Mon, Dec 06, 2010 at 02:08:36PM +0000, Michael Meeks wrote:
> > >   Really ? as soon as the X server dies, we'll get all manner of XErrors
> > > that will kill us nastily; I don't see a feature there, but perhaps I'm
> > > missing it.
> >
> > And that dying on XIOError is something we (i.e., Caolan and me) wanted
> > to avoid.
>
>       Sure - but I don't believe you'll do that here;

And you're absolutely right--I was so focused on the quickstarter I
didn't see the forest for the trees... The real problem is elsewhere
(see below).

> as you destroy the
> windows, you'll do a lot of X calls to free server resources that will
> just fail (surely).
>
> vcl/unx/source/app/saldata.cxx-int X11SalData::XIOErrorHdl( Display * )
>
>       does (essentially) _exit(0); which is about all you can do at that
> stage if you don't want to crash.
>
> >  Because otherwise abrt (Fedora's crash catching tool)
> > dutifully saves it and lets the user report it as a crash and we are
> > flooded (again) by reports like
> > https://bugzilla.redhat.com/show_bug.cgi?id=650170 .
>
>       Hmm, obviously not good. I couldn't see a stack trace there that I
> could read.

I have attached one.

> However - I don't see why the systray should be any
> different to having a top-level window open, or indeed any normal gtk+
> app getting getting nailed by a zapped X server. [ do you really file
> 10x bugs for different apps if someone does ctrl-alt-backspace to zap
> the server ? ].
>
> > I recognize this is not of general interest, though.
>
>       Nah - we should fix it; but - ... getting a good trace for it would
> really help. Is it from the g_error in the gtk+ X error handler ? do we
> really get a good grace period to cleanup from the session manager ?
> [ and just don't cleanup the systray applet there ? ] or ...

The problem is that SessionManagerClient is only initialized with the
first sal frame (IOW, GtkSalFrame::Show calls
SessionManagerClient::open). Obviously, if there has never been any
frame opened, which, I suppose, happens in a lot of cases, this hadn't
happened. So the app is not aware that the desktop session is ending and
continues to run, till it's killed by an XIOError.

I think the simplest thing here is to run SessionManagerClient::open
when initializing the quickstarter (the function is exported, so there
should be no problem with that), but there might be a cleaner solution.

D.