On lun, 2011-02-14 at 22:13 +0100, Wolfgang Lux wrote: > Germán Arias wrote: > > > Currently, in no document-based apps, the connection in Gorm of the > > outlet "initialFirstResponder" don't work if the window is > > configured to > > be displayed at launch time. Is necessary call -orderFront: in that > > window to get the expected behavior. This problem seems to be related > > with the problem of menu in window in no document-based apps. But the > > problem with -setInitialFirstResponder occurs with any style of menu > > and > > independently of the windows decoration. And I don't have idea about > > where is the problem. > > I see you have meanwhile found a solution to your problem (personally, > I dislike that code duplication, but I don't have a better solution > available). Nevertheless, your problem report here and the commit log > message indicate a misunderstanding of the problem that deserve > clarification. > > There was nothing wrong with the initialFirstResponder outlet in Gorm. > Recall that this outlet describes only the view that is the first > responder of a window when it is made visible for the first time. > Making a view the initialFirstResponder does not necessarily mean that > this view will receive key events when the window becomes visible.
I was accustomed to this behavior, so I thought it was the correct. One year ago I made a small tutorial to make a simple app on Windows, and I was accustomed to launch the app and immediately write into a textfield without use the mouse. But, as you explain, this is not necessarily the behavior. > > In general, it is also not sufficient to send -orderFront: to a window > to make it key window (though it works with many window managers under > X because they tend to shift focus to a window when it is ordered > front). To reliably make a window key, you should send it - > makeKeyAndOrderFront:. > > The situation is a little different when an application is launched, > however. If no window was made key explicitly (by sending it - > makeKeyAndOrderFront:), the application chooses one of its visible > windows to become key. Thus, if you have only one window, sending it - > orderFront: is sufficient in this special case. Your problem simply > was that due to the obscure logic -- that you rightly removed -- to > (ab)use the inactive window list when loading a nib while the > application is not active, the application had no visible menu (except > for the main menu) when it was looking for a window that could be made > key. > > Wolfgang > _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
