View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0023596 | Community | OCCT:Data Exchange | public | 2012-11-28 13:49 | 2018-05-25 19:18 |
Reporter | Roman Lygin | Assigned To | Roman Lygin | ||
Priority | normal | Severity | integration request | ||
Status | closed | Resolution | fixed | ||
Platform | A | OS | L | ||
Product Version | 6.5.4 | ||||
Target Version | 6.6.0 | Fixed in Version | 6.6.0 | ||
Summary | 0023596: Extending XCAFPrs_AISObject to enable customization of default color | ||||
Description | Added a virtual method DefaultStyle() which can be redefined in subclasses to provide a custom default style. The default style object has not been made a data member of a base class (XCAFPrs_AISObject) to avoid memory consumption, it is returned via an output parameter. For easier subclassing the Compute() method has been made protected. | ||||
Steps To Reproduce | N/A | ||||
Tags | No tags attached. | ||||
Test case number | Not needed | ||||
|
Pushed branch CR23596 into the git repository |
|
Branch CR23596 is ready to be tested |
|
In my opinion, it would be more convenient to have default color a member of the class, i.e. customizeable without subclassing. Does minor memory saving take sense in this case? |
|
Default style is per-application, not per-object. For setting the object's style one has to use XDE attributes, otherwise availability of member field to achieve the same creates ambiguity and hence confusion on when to use what. In 90%+ cases developers will unlikely redefine the defaults, so wasting memory for *every* object (which can be numerous, of course limited by OpenGL performance) does not look reasonable. Hence the subclassing approach makes most sense, imho. |
|
Ok, I see your point; why not static field then? Not a big problem anyway... |
|
The point against a static object would be for instance a lost possibility to have several kinds of 'default' styles in one application (e.g. solids would have one default style, sheets/shells - the other, wireframes - third and so on). Of course, a corner case but still a valid point which can be easily addressed by subclassing, without any extra global data. |
|
Dear BugMaster, Branch CR23596 (and products from GIT master) was compiled on Linux and Windows platforms and tested. Regressions: Not detected Improvements: Not detected Testing cases: Not needed |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-11-28 13:49 | Roman Lygin | New Issue | |
2012-11-28 13:49 | Roman Lygin | Assigned To | => gka |
2012-11-28 13:51 | Roman Lygin | Note Added: 0022408 | |
2012-11-28 13:51 | Roman Lygin | Status | new => resolved |
2012-11-28 17:24 |
|
Note Added: 0022417 | |
2012-11-28 17:24 |
|
Status | resolved => reviewed |
2012-11-28 18:27 |
|
Assigned To | gka => mkv |
2012-11-29 06:25 |
|
Note Added: 0022427 | |
2012-11-29 10:49 | Roman Lygin | Note Added: 0022432 | |
2012-11-29 11:00 |
|
Note Added: 0022433 | |
2012-11-29 11:24 | Roman Lygin | Note Added: 0022435 | |
2012-12-03 14:49 |
|
Note Added: 0022517 | |
2012-12-03 14:49 |
|
Test case number | => Not needed |
2012-12-03 14:49 |
|
Assigned To | mkv => bugmaster |
2012-12-03 14:49 |
|
Status | reviewed => tested |
2012-12-10 17:16 | Roman Lygin | Changeset attached | => occt master 576ab394 |
2012-12-10 17:16 | Roman Lygin | Assigned To | bugmaster => Roman Lygin |
2012-12-10 17:16 | Roman Lygin | Status | tested => verified |
2012-12-10 17:16 | Roman Lygin | Resolution | open => fixed |
2012-12-10 17:47 | bugmaster | Target Version | => 6.6.0 |
2013-03-01 21:39 |
|
Relationship added | has duplicate 0022570 |
2013-04-23 13:35 |
|
Status | verified => closed |
2013-04-29 15:23 |
|
Fixed in Version | => 6.6.0 |