[Bf-committers] Oops Redesign proposal.

[Campbell Barton]

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.
- 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.

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)
    * 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.

      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.
    * Rework the oops block display- not related to anything above but
      would be nice.

 As sombody who uses the oops view in most of my projects depricating 
the current oops is the last option, but worth the effort... incase its 
not clear- this would be a project I would do all/most of the work on so 
Im mainly seeking opinions and comments- its a lot of work me to do and 
not have commited at some point.

The custom dataproperty would be a great advantage for content creation 
with games, simulation, rendering etc...
Can we afford to add 2 pointers to the ID struct? (probably dont want 
properties assigned to the oops blocks)

There are other midway solutions (oops datablocks share locations) or 
add a property editor to the current oops view, but Id prefer to re-do 
the whole thing.
If depricating the oops view is just not an option, we could add a view 
more focused on property editing but still has on oops layout....

- Cam

-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241