Sun 13 Apr 2014 03:57:09 PM UTC, comment #11:
For locale-specific defaults, is it as simple as using the existing site-wide octaverc file to set defaults?
I have 3.8.1 installed in /usr/local and the relevant file is /usr/local/share/octave/3.8.1/m/startup/octaverc.
You could place a bunch of commands like
in that file.
|
Sun 13 Apr 2014 03:29:25 PM UTC, comment #10:
We are getting a build failure due to the changes applied so far for this bug:
http://hydra.nixos.org/build/10317330/log/tail-reload
I pushed the following change to fix this error:
http://hg.savannah.gnu.org/hgweb/octave/rev/93d0fc8a5d86
|
Sun 13 Apr 2014 08:42:44 AM UTC, comment #9:
Hello Rik,
Thanks for the review of all those patches.
I checked the properties you mentioned in matlab:
"cameraupvector" value depends on the type of object (and probably the current axes "view" property), but its factory value is not conform to their documentation.
"alphadatamapping" is not conform to their documentation neither, at least in the version I use for testing.
Coming back to my interrogation, do someone have an idea on a central place to set non factory defaults? E.g. locale specific defaults (papersize, paperunits) could be set there (as a European I'd really be happy to not mess with those esoteric inches :-).
|
Sat 12 Apr 2014 08:40:23 PM UTC, comment #8:
Now that image objects have a DisplayName property, they should be supported by legend(). I filed a separate bug report about that feature here https://savannah.gnu.org/bugs/?42103.
|
Sat 12 Apr 2014 08:31:25 PM UTC, comment #7:
I modified your patch slightly for Octave coding conventions. We place the '++' modifier directly next to the variable, e.g., 'C++' rather than 'C ++'. We also prefer to use the C++ casting standards so I changed
I checked it in here (http://hg.savannah.gnu.org/hgweb/octave/rev/2deed6538c72).
Could you double-check two of the values?
According to http://www.mathworks.com/help/matlab/ref/image_props.html the default for AlphaDataMapping is 'scaled' (what it was before) rather than 'none'.
According to http://www.mathworks.com/help/matlab/ref/axes_props.html the default CameraUpVector is [0 0 1], rather than [0 0 0].
|
Sun 06 Apr 2014 04:53:30 PM UTC, comment #6:
Sorry if it looks like I use the bug tracker to show my drafts but each time I come back to this bug I discover something new.
In ML as in octave you can display all the root defaults using "get (0, 'default')". Matlab result :
So you can see all the "color" properties I described, but also some run time defaults for figures and axes properties.
In octave the result depends on wether the graphics toolkit (Qt here) is loaded:
My impression is that, if we want to be reasonably compatible with ML here, there should be a central place where defaults (toolkit specific or not) are set at startup (or after a neww toolkit has been loaded) .
Even if we don't want to follow matlab on every choice (such as the default figure color) it can be usefull to reassemble all non-factory defaults in one place.
Is there a convenient place to do that? Any comment?
|
Sun 30 Mar 2014 09:36:04 PM UTC, comment #5:
I attached a new version of the patch.
I added "octave-default-image.h" in libinterp/corefcn. It contains the octave logo (64x64 char array) indexed against the "Jet" colormap.
Remaining issues:
*'surfaceedgecolor', 'patchedgecolor', 'patchfacecolor', 'linecolor' (see comment #4): if we want to be fully conform with ML factory defaults, those properties values will have to be changed at startup (using e.g. "set (0, "defaultPROPNAME", VAL)").
*'surfacefacelighting', 'patchfacelighting': factory values should be 'flat' instead of 'none' but the current implementation in openGL renders black surfaces/patches. I think we should wait until the bug (bug #42006) is solved before setting the correct values for those properties.
(file #31080)
|
Wed 26 Mar 2014 10:09:39 PM UTC, comment #4:
cdata: should octave logo be loaded (and how) at run time or included from a data header file at compile time?
color:
AFAICS, octave and ML perform pretty much the same (see the diagram in [1]). The thing is for lines ML has to change the line default at run time. Looks like internal cuisine that leads to weird behavior after reset. If it as acceptable to not have the same factory default here, I would not try to mimic this ML behavior.
In ML you can retrieve root level (default && !factory) for a given graphic object type using "get (0, 'defaultOBJTYPE')"
Now about "displayname", forget about it: the error message is the same with or without the added property. I did not investigate but it looks like images don't qualify as an "legendable" object. I would add the property, and file a bug report for legend.
Finally, I'll have to rework the patch anyway as I just noticed it breaks "surface ()" default behavior.
[1] http://www.mathworks.fr/fr/help/matlab/creating_plots/setting-default-property-values.html
|
Wed 26 Mar 2014 08:21:47 PM UTC, comment #3:
For cdata, how about just embedding the data for the Octave logo?
For the line color property, do Octave and Matlab behave differently for
? Is Octave just not using the defaultlinecolor propertly correctly when drawing lines? Is this unique to lines, or is it a deeper problem with all default properties?
I'm not sure what to do about the image displayname property. What's the exact problem with legend?
|
Tue 25 Mar 2014 10:45:15 PM UTC, comment #2:
I see I have missed some of the non conforming factory defaults. I updated the patch but some differences remain.
The main one is in image properties: "cdata" should contain the factory image (double [64x64]) color data. Is there such default image that can be read in octave tree (preferably without requiring GraphicsMagick)?
Some other minor problems:
- line: "color" should be [1 1 1] (but then "line ()" returns a white line). In ML black color is set in root "defaultlinecolor" so that if you "reset (0)" you fall back to factory defaults and also obtain white lines.
- text: "clipping" should be "off" but as it belongs to base_properties it is "on" by default for every graphics objects. Same problem with "color" as for line objects.
- patch: "facecolor" same color problem
- image: should have a "displayname" property. Adding this property is easy but then legend fails when there is an image in the axes.
(file #31038)
|
Mon 24 Mar 2014 08:43:27 PM UTC, comment #1:
Pantxo,
I applied your patch and confirmed that all graphics.cc tests pass for me on MacOSX.
|
Tue 04 Mar 2014 12:45:26 PM UTC, original submission:
I have only investigated defaults returning empty matrices that shouldn't. This is not a big issue as they are updated when an object is created but querying their factory value doesn't return the expected value as in Matlab (attached matlabfactory.mat file).
You may try the following in octave 3.8 or dev:
I also attached a patch that make this test script pass (and all tests in graphics.cc still pass)
|