Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exclude keyWindow occupancy #56

Closed
liuzhiyi1992 opened this issue Jun 21, 2018 · 6 comments
Closed

Exclude keyWindow occupancy #56

liuzhiyi1992 opened this issue Jun 21, 2018 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@liuzhiyi1992
Copy link

liuzhiyi1992 commented Jun 21, 2018

Is your feature request related to a problem? Please describe.
EKWindow occupy application keyWindow while enrty attaching.
its overset any case to fetch correct application keyWindow, about present in keyWindow, about traversal with keyWindow

Describe the solution you'd like
should we show EKWindow used windowLevel-control like UIAlertViewController? That would not disturb the hierarchy of application windows

Describe alternatives you've considered

Additional context
i wish the better development with SwiftEntryKit

@huri000
Copy link
Owner

huri000 commented Jun 21, 2018

Please explain the issue according to the suggested template in the project.
Deleting the template is an act of violence 🙂
Please tag this as Feature Request.

@liuzhiyi1992
Copy link
Author

haha, my mistake

@huri000
Copy link
Owner

huri000 commented Jun 21, 2018

Thanks for updating the issue!

EKWindow occupy application keyWindow while enrty attaching.
its overset any case to fetch correct application keyWindow, about present in keyWindow, about traversal with keyWindow

I understand that if you have another window as key-window, replacing it and going back to the app key window will disturb the window hierarchy. You are right.

should we show EKWindow used windowLevel-control like UIAlertViewController? That would not disturb the hierarchy of application windows

Do you mean present as modal view controller? Alerts are eventually presented in their own window so that's pretty much the same as what SwiftEntryKit does.

Maybe the right solution would be receiving a fallback window object to go back to.
When SwiftEntryKit has done displaying, the given fallback window would be set as key window.

What's your opinion?

@huri000 huri000 self-assigned this Jun 22, 2018
@huri000 huri000 added the enhancement New feature or request label Jun 22, 2018
@huri000
Copy link
Owner

huri000 commented Jun 22, 2018

Manipulating the window-hierarchy is what SwiftEntryKit is all about. As a solution to a situation of a fallback window (In which a developer already has a key window he wants the app to go back to), I'm gonna add a fallback window as a parameter to present and assign the main app window as its default value.

@huri000
Copy link
Owner

huri000 commented Jun 23, 2018

Resolved in 0.5.0 using an alternative window for a rollback.

@huri000 huri000 closed this as completed Jun 23, 2018
@liuzhiyi1992
Copy link
Author

liuzhiyi1992 commented Jun 24, 2018

morning huri000, i think fallback only is not good idea, key window position still occupied throughout the entry display with the different of system alert window, the problems that you cant uses key window to present or find some content in it hierarchy during entry window displaying, simultaneously, it will terminate first responder while entry display, this causes infection to the behavious of host app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants