OS X 10.4 menu bar problems

Strange annoying problem which I think is related to 10.4 (I'm using  
10.4.2).  I have an interface where I open a find window using a menu  
accelerator. When the window is closed the menu title of the menu  
used to launch the window from the first interface is still  
highlighted. I say it is related to 10.4 because I don't recall  
seeing it before and I'm also have this problem with one other non- 
Lispworks application. It happens all the time in my delivered  
application, but never in LispWorks using the same interfaces.

I have already mucked around with this for a couple of hours and I  
can't find a way to fix it. Any ideas?



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

Re: OS X 10.4 menu bar problems

John DeSoi <desoi@pgedit.com> writes:

> I have already mucked around with this for a couple of hours and I
> can't find a way to fix it. Any ideas?

I've seen this in a delivered application that was delivered with
LWM without Lispworks' Tiger patches - do you also see it if you
deliver with the Tiger patches installed?

--
  mvh,
    Espen Vestre
    Netfonds ASA

Re: OS X 10.4 menu bar problems

John DeSoi <desoi@pgedit.com> writes:

> (load-all-patches) is one of the first things called in the delivery
> script. From the output I have:

OK!

I reread your mail and realised that my situation is a little bit
different, I have a window opened with a menu item (and without an
available accelerator). If I switch to a different window (while
leaving the "offending window" open), the menu title is still
highlighted. Moreover, I think I found the problem: I noticed that
this only happens with a specific window that doesn't have a menu bar
of its own (I have now verified that the bug exists with the
tiger patches installed).

BTW: The menus of my application are amazingly slow the first time I
use them after startup, I sometimes have to wait up to 10 seconds
for a response. Can I do something about this? Could it be caused by
a sub-menu containing all available fonts?
-- 
  (espen)

Re: OS X 10.4 menu bar problems

John DeSoi <desoi@pgedit.com> writes:

> Fonts could definitely be the problem. Take a look at all of your
> menus where you have a function that dynamically generates the items.
> Perhaps by disabling the function(s) you can determine the source of
> the problem. I'm not seeing any speed problems with menus.

Thanks, that's useful information.

(Now: How do easily and cleanly filter out all those east asian fonts
      from my dynamic font menu? - that would sure help a lot!)
-- 
  (espen)

Re: OS X 10.4 menu bar problems

John DeSoi <desoi@pgedit.com> writes:

> I'm not familiar with the needs of your application, but my offhand  
> suggestion would be to eliminate the font menu. Hardly any OS X  
> application use a font menu; most use the font book interface  
> available from capi:prompt-for-font. I think this has better  
> usability and more features than trying to list fonts in a menu.

(I'm working on this problem again today, thus the late reply)

I'm a little confused here - how is capi:prompt-for-font supposed to
work on OS X? capi:prompt-for-font works as if it were a modal dialog
- but it isn't, the Mac font window is supposed to be a floating tool
window. As far as I can tell, it's not possible to supply callbacks to
capi:promt-for-font, so the only way to use it is by selecting the
font and then - very counterintuitively! - /close/ the window.

I'm looking for two possible ways out of this, and would be happy
for solutions to either of them:

either a) a way to make find-matching-fonts /not/ return non-european
fonts
or b) a way to use prompt-to-font that doesn't confuse the user.
-- 
  (espen)

Re: OS X 10.4 menu bar problems

John DeSoi <desoi@pgedit.com> writes:

> Yes, you are right. prompt-for-font was created in a modal way to  
> make it conform to the capi API. So I guess your only option here  
> would be to do a bit of Objective-C programming to make it work  
> right. My guess is that bringing up the font panel is simple, but no  
> telling about how hard it would be to capture the events and make it  
> work with capi.

I think I'll stick with my current interface (I've redesigned it to
compute the font list on application startup so it's not as resource
consuming) and hope that the Lispworks guys will consider changing the
somewhat confusing promt-for-font for the next version (at least make
it like the prompt-for-color interface where there's a "done" button)
-- 
  (espen)