[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