[Bf-committers] Re: Oops Redesign proposal.
gsr.b3d at infernal-iceberg.com
Sun Jan 29 22:27:39 CET 2006
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
> 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
> 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)
> - 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.
More information about the Bf-committers