[Bf-committers] Notes on interface/event/window system

[Daniel Dunbar]

Euh, it really wasnt about the conclusion, mostly the purpose was
to explain a bit about how it works now. I do think that the
Space and ScrArea should be merged for simplicity reasons, but
that is not something I am really proposing to do atm.

--- Ton Roosendaal <ton@blender.org> wrote:
> Hi Daniel,
> 
> Thanks for the article!
> I don't agree with (or don't understand :) your conclusion, especially  
> the assumption:
> 
>  > In most operating system environments the
>  > window and the contents of the window are treated as one.
> 
> This is in my opinion not correct. I think it makes sense to  
> distinguish a window-manager from user-interface functionality. The  
> distinction betweeen 'Screen Area' and 'Space' in Blender is exactly  
> that. In traditional systems, the Screen Area would be part of the  
> window manager, and never be coded in the app... in that sense Blender  
> is confusing.

No, in traditional systems the window is still created and interacted
with by the application. In most GUI toolkits you create a new application
window by subclassing the base window class. In this case an application
window *is-a* operating system window from the API point of view.

> I agree with your observation that the Space switching hardly is used  
> in Blender, except for File loading. Plus it has been abused, like how  
> buttons for the view3d window have to be accessed.
> 
> However, it is part of the design of this non-overlapping  
> subdivide-screen interface. You need a method to  configure that  
> interface, and allow the user access to the various editors.

I agree, there does have to be some way of switching an area of
the screen to a different editor. I just don't think the current
system is the correct metaphor.

> Also, for the programmer the concept was to simplify adding new editors 
> by just creating a couple of 'callback' functions, like winqread() and  
> windraw(), and a 'Spacedata' structure holding the relevant info that's  
> saved to a file.

Yes, I understand this ;)
For the most part this has nothing to do with the current design though,
a unified Space/ScrArea would be similar. Actually my primary motivation
is to make more information be in the SpaceType - again, with the intent
that to define a new space all you need to do is provide an appropriate
SpaceType structure.

> Isn't the weakest point in the design that the *actual* separation  
> between window manager code (screen.c mywindow.c) and interface code  
> (space.c) is highly spaghetti-fied? Like what you mention in the end of  
> your notes, the Screen data structure and ideas how to treat the  
> blender window headers...

I think the weakest point is just that there are so many related but 
disparate elements in the design. To do actual 'interface work' on a
space you need to have access to its ScrArea and its windows (to determine
the context of events, and to be able to interact with the window). So
if everywhere you have a spacedata pointer you are going to need a 
ScrArea point to do actual work, then you should just start by combining
the two.

> For a review of the interface system, it might be handy to classify  
> remarks like this:
> - the design specs
> - the implementation
> - how to improve or change the design
> The fact that there's no written 'design spec' makes discussions about  
> the interface implementation highly confusing, something I find in your  
> text as well... Is your suggestion to unify 'Screen Area' and 'Space' a  
> better implementation or a new design? I really don't understand what  
> purpose it would serve.

I thought my note at the bottom made it clear I was just talking about
the implementation, none of my remarks were aimed at changing the actual
user interface. And again, it was mostly written to be notes on how it
works now, changing it right now is not my highest priority.

For what I do want to change right now I have to get back to writing ;)


=====
daniel dunbar
daniel@zuster.org