[Bf-committers] Re: Oops Redesign proposal.

Campbell Barton cbarton at metavr.com
Mon Jan 30 03:52:08 CET 2006


GSR wrote:
About multiple oops layouts- If there needed it can be done the way Im 
suggesting - Just store the multiple locations within each oops block.\
If multiple layouts are important then Id make named layouts that could 
be added, selected and removed.  - like datablocks.

Would still like to get an idea from others weather multiple layouts are 
realy needed.
...few comments inline.
> 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?
Yep- if you spend a lot of time on the layout - its more of a loss then 
the 3d view tho.
>> - 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?
>   
Would have to be evaluated- but its possible that a new design might 
make it very tircky.
>>     * 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
>  
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>   


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


More information about the Bf-committers mailing list