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

Multiple native window support #9772

cboulanger opened this issue Aug 13, 2019 · 2 comments


Copy link

commented Aug 13, 2019

Note: This is a feature that will be worked only after the release of version 6. I enter it here as a note-to-self kind of issue.

qooxdoo currently lacks the ability to extend itself into multiple native windows. This, however, is the prerequisite for creating truly desktop-like applications. The MDI-Style Desktop with qx.ui.window.Window widgets does not cut it when you really need to work simultaneously in different windows.

A programmatically opened native window has no problem accessing the top windows qx object, but events do not work in that window. The main technical problem seems to be event registration which is currently tied to the main context. I investigated this a couple of years ago and if I remember correctly, any fix is non-trivial. There is some discussion about that on the old sf-list, but the issue needs to be revisited at a later point.

@cboulanger cboulanger self-assigned this Aug 13, 2019

@cboulanger cboulanger added this to the release_7_0_0 milestone Aug 13, 2019


This comment has been minimized.

Copy link

commented Aug 13, 2019

There is support in the event queue AFAICR to support different window objects, so maybe this is a case of implementing the last 10%... but I would anticipate problems in trying to implement this, eg including browser ever tightening security protocols.

One solution which is really clean and least likely to be blocked by the browser is to allow each native window to have its own compiled application and then to define an API - communication happens via postMessage() calls, which avoids any potential security issues.

Would that work for your use case?


This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

You're right that the situation has changed compared to the old generator-times: we now have multiple-app support out of the box - so I could in fact create a separate app for each window and reuse all the existing classes to compose it. - Thanks, I haven't thought about it this way. Maybe that's indeed enough for my use case.

But still, I think we should look into whether multi-window support can be made possible, since it makes it somewhat less complex to solve the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.