Go?

[Zini]

The blender subwindow handling system kinda does make sense (assuming you want to work with subwindowing) for an application as complex as our Editor. Just make sure that it is kept optional.

[pvdk]

You mean the switch approach we've discussed before: switch between this and multi-window (GIMP) mode?

[Zini]

Please stop calling that GIMP mode. For most parts GIMP is an example of how not to do multiple window GUIs.

Anyway, I think the consent was that the user can have as many top level windows as he wants, where each window can have one or more component views in it. That should also work nicely for a blender type interface.

[pvdk]

Please stop calling that GIMP mode. For most parts GIMP is an example of how not to do multiple window GUIs.

Oh yeah, I forgot. I'll call it Multiple top-level window mode then. Together with the Blender-type interface and a configuration option to switch between those modes it should make for a nice interface. Multiple QMainWindow widgets isn't going to work though, as that would give issues on Mac. But I'm sure we can figure something out.

[Zini]

Oh yeah, I forgot. I'll call it Multiple top-level window mode the

Together with the Blender-type interface and a configuration option to switch between those modes it should make for a nice interface.

I agree. Ideally a user should be able to decide on a case by case basis, if he wants a new component view to be opened in a new sub-window or in a new top level window (let's say by holding down shift while performing an action that opens a new view). If that proves to be too much work a single global option would work too. The ability to move component views between top level windows would also be a nice addition.

Pondering a bit about the implementation (discard any of this if you don't find it useful; I am working here mostly with guesswork about Qt's capabilities):

Any chance that the view handling/windowing system and the actual component views can be orthogonalized? Let's say we have a base class for the component views.

The actual components should be agnostic about the windowing system, while the windowing system works without knowing anything about concrete component view classes. The windowing system could even be developed into a separate framework later that can be re-used for other applications, because it sounds rather useful (but let's things not get out of hand for now; we can look into that another time).

The component view base class would provide the concrete classes with a component view specific Qt-widget (either as a base class or a member; however you funky Qt kids do it these days) and this would be all the concrete component views would need to know about the GUI. For common functionality the base class should provide functions that need to be implemented by the derived classes (e.g. check if data displayed in this view has been modified; locking; cloning for a new view; ingoing/outgoing drag operations), while functionality that is not specific to concrete component views should be kept completely out of them (e.g. closing the view, moving the view to a new top level window).

The main advantage of this approach is that the windowing system and the concrete components could be developed independently of each other once the base class interface has been defined, e.g. the windowing system and specific component views could be worked on in parallel by several people. It might also not be necessary to develop a perfect and fully polished windowing system now, if you can get the component view abstraction right. You could very well develop a basic windowing system and add more functionality (like moving views between top level windows) later.

[Tarius]

The one thing I can say here is: "Customizable"
You make it so that people can move stuff around to how they like it and most people will be happy.