The exisisting PropertyList serialization is deprecated. This has to wait until a new serialization mechanism is available. (See T2130)

Party bug with low priority.

Assigning this to default assignee because mbi-bug-manager is not a person and cannot evaluate/reassign this bug. Would you please assign it to the correct product/component and estimate whether it is relevant for the 1.0 release? Thank you.

Is this still relevant? Maybe a party bug? I won't have time for this.

A very old bug/idea. Reassigning this since Stefan is working on this now.

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

Why did this bug come back to me (check History)?

I still think this is an important feature. I know we did not include it in Stefan's property project, but maybe he or Caspar could comment if there were some ideas how to implement this to make it partyable.

If I understand the issue correctly, by configurable properties you mean what properties are visible to the workbench user? - That can be easily done with the new property services which are part of the new property view commit. There is a black and white list filtering approach deciding which properties are visible. Currently they are set in the source code but it shouldn't be hard to introduce a config file for black/white list initialization.

My understanding was, that the bug concerns itself with configuring the content of the default properties instead of the visibility.

E.g. Change the default name of an image from "NoName" to "Unbenannt" if one wants a german localized application.

Hm, OK, but that would make sense only for a very few properties (if any) since they are created based on the image file contents/name, e.g. the name is the file name and usually you wouldn't assign each and every image the exact same name.

Well, you could for example add a new default property:

"Created by" - "Your Company here"

or change existing ones

"visible" - OFF

or change existing ones for a specific data type

"planarfigure.hover.line.color" - "9.4.2"

While your first example is true (but questionable in sense since the property view would be definitely the wring place for that info), I think the other both cases would introduce too much additional state (AKA chaos) to MITK. It would easily affect nearly each mapper (loads of additional conditional branches for default properties). This is - in my opinion - not worth the effort and should be solved by clients of MITK if needed, since their use cases are usally orders of magnitude smaller than the generic MITK with all functionalities for which we must kind of guarantee that they are working.

Would it be that much work? Without looking in the code I would envison something like (Pseudocode):

newNode->SetData( AwesomeFilterGeneratingABlubb->GeneratOutput() );
newNode->SetProperties( defaultPropertySetService->GetDefaultProperties( "Blubb" ));

where the defaultPropertySetService loads on startup the presets.xml:

...
<defaultProperties>

...
<Blubb>
  <property id="name" content="Unbekannt"></property>
  <property id="visible" content="false"></property>
  <property id="planarfigure.hover.line.color" content="9.4.2"></property>
</Blubb>
...

</defaultProperties>
...

This would of course not work for LookUpTables or similar, although in that case you might add a "type" and "path" tag.

In your example the appropriate mappers would create their default properties first during the call to newNode->SetData() and draw everything (and execute other code as well). After that, the service would change some of these properties and issue a new draw command. That can only cause evil. :D

To prevent this behavior with our current architecture you would need to handle the service form inside each involved Mapper::SetDefaultProperties() to initialize each property only once with its appropriate value.

That's why I'm thinking this is not worth all the effort, especially since it is not a high priority feature request or even needed to get MITK working.

BTW, was there any other serious request for this feature since 2009? :)

I do not know whether it was requested again, but I think it would be appreciated to be able to do some custom configurations without having to touch the code.

The SetDefaultProperties() function of the could check whether custom default properties are registered, if not, it sets their own. Alternatively we could move all default properties to the file, so that the mapper can always take the ones provided by the service. In that case it is the obligation of the user to make sure he does not delete needed properties...

To summarize the discussion about this subject:

Aim of this issue is switching the default properties from the current implementation (each mapper knows its own default properties and sets them for a node) to a service based architecture (each mapper registers the properties it uses for the correspondings data types). This way it is possible to combine the properties used by multiple mappers for the same datatype. Furthermore the xml representation of proplists allows saving/loading of default propery schemes and editing them without changing the source code.

Assigning to Keno, as this was just discussed in his plattform project talk.

I feel venerated to take responsibility for this time-honored bug. It will most probably be out of scope for my project to implement a complete solution, but I should be able to at least define and implement an API for the proposed changes. I will then close this bug and open a new one with specifics for the implementation.

This bug could not be fixed within the 2013-06 release and has medium severity. Setting target milestone to unspecified.

This bug could not be fixed within the release 2013-06. Setting its target milestone to unspecified