slow xfce menu?

[Brian J. Tarricone]

On 10/20/04 11:23, Andrew Conkling wrote:
> Some time ago (probably on Tue, 19 Oct 2004 21:17:32 -0700)
> "Brian J. Tarricone" <bjt23 at cornell.edu> had occasion to say the following:
> > 
> > 'xfdesktop -reload'.  the problem is that if an app installs a .desktop 
> > file to /usr/share/applications, the menu needs to be regenerated.  the 
> > app installer doesn't know how to do this, and the user shouldn't need 
> > to have to.  so it polls every 10 seconds to see if anything's changed, 
> > and regens as needed.
> 
> Ah, I was not thinking of system menus, only user ones; I guess this
> scenario would have to be covered as such.  However, back to the original
> question, if xfdesktop polls every 10 seconds and regenerates as needed,
> then why would there be a performance lag when accessing the menu after a
> period of disuse?

there shouldn't be.  it also does a check for changes when you click to
make it appear, but there shouldn't be a delay unless it actually needs
to be regenerated.[1]  the issues here:

1) if something makes a change, and you don't use the menu for a while, the
ten-second poll will catch it and by the time you access the menu, it will
already have regenerated, so there won't be a delay at all.
2) if something makes a change, and then you access the menu within ten
seconds, we check, see that it needs to regenerate, and do it.  the downside
here is that you can see a several-second delay before the menu is drawn.
now, if i _don't_ do this:
  a) the menu is outdated as you see it.
  b) if you still have the menu open when it gets to its first 10-second
  check after the change occurred, the menu will get destroyed and will
  disappear off the screen.

there are some architectural mistakes i made that, if remedied, might
alleviate some of these problems.  there are probably a few hacks i could
implement to help as well.  but they're too risky at this point in
development, and the menu is going to be replaced in 4.3 anyway, so i
don't want to waste time doing the work and requisite testing.

> > >It seems like having xfdesktop only "listen" to the menu editor would not 
> > >break from Xfce's current programme behaviour.
> >
> > oh, but it would...  the bottom line is that, if the menu needs to be 
> > regenerated, it should be, and xfdesktop should do it.  period.  if it's 
> > regenerating when it doesn't need to, then it's a bug i want to fix, but 
> > otherwise, there's no bug here.
> 
> Yes, I see what you mean now.  But, just to make my question clear, what
> about if it's not ready when the user accesses it, because it needs to
> regenerate or something else?

as i said, the user will see a delay between the time they click and when
the menu is drawn.  this is the _only_ time there should ever be a delay.

[1] If for some reason you have files/directories that need to be checked
that are on network volumes, there might be other delays associated with
network performance problems.  not much i can do about that at this point.
my recommendation here is that you just don't use the system menu in this
case.

	-brian