Go?
Re: Go?
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.
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.
Re: Go?
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 wrote:Please stop calling that GIMP mode. For most parts GIMP is an example of how not to do multiple window GUIs.
Re: Go?
Oh yeah, I forgot. I'll call it Multiple top-level window mode the
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.Together with the Blender-type interface and a configuration option to switch between those modes it should make for a nice interface.
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.