[Bf-committers] Re: Oops Redesign proposal.

[GSR]

Hi,
cbarton at metavr.com (2006-01-27 at 1110.06 +1100):
> Hello all... from messing about with oops code for a while I have come 
> up with this...
> The current oops design is such that each window has its own oops data 
> (oops layout, linked list for its own oops blocks).
> can be a problem because most of the time I just want 1 oops layout...
> related problem is that joining a window will loose your oops layout 
> without warning.

Same way you lose 3dviews, correct?

> - If this was the only problem I could follow tons suggestion and have 
> an Oops copy/paste function so as to take the oops layout from 1 window 
> into another..
> 
> For my use Im happy with 1 oops location per datablock (1 oops layout 
> for all oops views), in some cases it may be usefull to see the same 
> data multiple ways but AFAIK not that many people even use the Oops view 
> let alone manually laying  out multiple oops view.

Poor OOPS has always been the forgotten, underpowered, kid, so it is
normal that it gets underused. If it get a nice cleanup (and I do not
mean candy, but functions) then you could reevaluate the point about
unified vs multiple layouts. I can imagine some kind of view in which
you group by kind (to do material to object assignation, for example),
and another in which you create a schematic of your scene (sticky
figure for character parts, etc).
 
> Refactoring oops could be done in many different ways but Ill suggest 
> what I consider the best option first.
> 
>     * Depricate the current oops view - (Could keep it for compatibility
>       and have function to copy the data to the new oops)

No migration at all?

>     * Rather then having oops data per view- have each ID struct point
>       to an oops struct (NULL by default)
>       This means every ID has 1 oops. at the moment getting an ID's oops
>       block involves a full listbase lookup wich can be slow on large
>       scenes.
>       Doing this also means we can avoid having oops spesific linked
>       lists. - just loop through blenders object, etc.

Would this mean multiple OOPS layouts possible?

>       This would have faster operation, There are some scenes where its
>       been quicker to kill blender and reopen it then to wait for the
>       oops data to be generated, when selecting the oops view by mistake.
>       Because of the number of loops- larger scenes quickly become slow.
>       Or wait for it to finish and then join the windows to free memory.
> 
>     * Add a custom property editor into the oops view!
>       The oops view is the only place where (almost) all datablocks can
>       be seen at once and there is only 1 item per datablock (unlike
>       outliner)
>       I could intergrate a custom property editor so the active Oops
>       ID's property could be edited on a floating panel. (think the
>       modifier stack)
>       http://en.wikibooks.org/wiki/Blender_3D:_Blending_Into_Python/CustomProperties  
>       -   for some design ideas on custom datablock properties.

This seems a good cause of multiple OOPS, be able to assign properties
with a layout for that, while you can have other with the more spacial
one of sticky figures.

GSR