Widzę, że ilekroć aplikacja taka jak Mac Chrome zawiesza się, wyświetli pokrętło i przestanie odpowiadać. To jest to samo zachowanie, co w przypadku systemu Windows, ale zauważyłem osobliwość dla komputerów Mac:
Dlaczego powieszone okna Maca można nadal przenosić i deminimalizować, ale nie można ich zminimalizować ani zamknąć?
Czy istnieje techniczny powód / uzasadnienie / wyjaśnienie tego dziwnego zachowania?
Odpowiedzi:
Nie ma technicznego „prawa”, które wymagałoby, aby którekolwiek z nich było w ten czy inny sposób, więc wszystko sprowadza się do tego, jak deweloperzy macOS postanowili zbudować system. Dlatego każde uzasadnienie lub wyjaśnienie może być wyjaśnione tylko przez to źródło - wszystko inne to spekulacja.
Spróbuję jednak spekulować, dlaczego macOS zachowuje się w ten sposób!
Aby zrozumieć logikę, musisz zrozumieć, jak działają programy graficzne macOS. Podobnie jak Windows, każda uruchomiona aplikacja ma tak zwaną „pętlę zdarzeń”.
Zasadniczo części systemu operacyjnego odpowiedzialne za tworzenie graficznego interfejsu użytkownika komunikują się z każdą uruchomioną aplikacją poprzez wysyłanie komunikatów („zdarzeń”) do aplikacji. Aplikacje działają poprzez ciągłe odczytywanie tych komunikatów z kolejki w tak zwanej pętli zdarzeń.
Wiadomości mogą być takie jak „Użytkownik przesunął mysz”, „Użytkownik kliknął przycisk X”, „Użytkownik chce zamknąć okno Y” i tak dalej.
Kiedy graficzny interfejs użytkownika dla uruchomionej aplikacji zawiesza się i pojawia się pokrętło, oznacza to po prostu, że aplikacja przestała przetwarzać te zdarzenia. Być może przestał to robić, ponieważ się zawiesił, utknął w nieskończonej pętli lub ponieważ jest naprawdę zajęty robieniem czegoś innego (co może być w pełni produktywne).
System operacyjny naprawdę nie jest w stanie stwierdzić, czy aplikacja nie odpowiada, ponieważ uległa awarii, ponieważ jest zajęta robieniem rzeczy lub dlatego, że komputer działa wolno. Jedyną heurystyką, którą mają, jest jej czas - jeśli upłynie zbyt dużo czasu, wyświetlamy pokrętło.
Teraz możesz argumentować, że system operacyjny może po prostu zamknąć program, ale możesz stracić cenne dane. Jeśli wiesz, że program jest zajęty robieniem czegoś za Ciebie, możesz poczekać kilka sekund lub cokolwiek innego - program przetwarza zdarzenia i możesz zapisać swoje dane.
Najprawdopodobniej to użytkownik decyduje, kiedy „wystarczy wystarczy”, a ty chcesz zakończyć program.
Teraz wydarzenia przetwarzane przez program będą w nowoczesnych warunkach często przetwarzane przez delegatów. W przypadku twojego pytania chodzi o NSWindowDelegate, która w zasadzie obsługuje różne rzeczy, które mogą się zdarzyć w oknie. Zauważ, że okno nie jest aplikacją na macOS - zamknięcie okna tylko zamyka to okno, a nie cały program.
Jeśli spojrzysz na NSWindowDelegate:
https://developer.apple.com/documentation/appkit/nswindowdelegate/1419461-windowwillminiaturize
przekonasz się, że programy mogą reagować na zdarzenia takie jak „windowWillMiniaturize” (tj. użytkownik zażądał, aby to okno powinno się zminimalizować) i „windowShouldClose” (tj. użytkownik zażądał, aby to okno zostało zamknięte). Program może zrobić coś ważnego po otrzymaniu tych zdarzeń - coś ważnego, co musi zrobić, zanim zostanie faktycznie zamknięty lub zminimalizowany.
Ale co się stanie, gdy program nie przetwarza tych zdarzeń? - System musi po prostu zatrzymać te operacje, aby zapewnić, że program będzie miał szansę zareagować na zdarzenia, zanim coś się wydarzy. Dlatego nie można minimalizować i zamykać okien, gdy pokrętło jest widoczne.
Należy jednak pamiętać, że delegat nie zawiera „windowWillDeminiaturize” - tylko „windowDidDeminiaturize”. W związku z tym macOS nie musi blokować de-minimalizacji okna, ponieważ nie ma obowiązku poinformowania programu, zanim deiminimuje okno. Musi to dopiero potem powiedzieć!
źródło