Sat 13 Sep 2014 03:08:40 PM UTC, comment #14:
Yes, I followed your advice and bravely pushed a second one :-)
|
Sat 13 Sep 2014 01:04:46 PM UTC, comment #13:
Good. Often the only way to get significant testing done is to push the change.
|
Sat 13 Sep 2014 09:26:14 AM UTC, comment #12:
Hi,
Thank you ben. I went ahead and pushed the changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/dc88c5784f74). Closing bug report.
|
Mon 08 Sep 2014 01:12:51 AM UTC, comment #11:
I can confirm the patch fixes the prior examples for figure and axes objects.
I'm not sufficient familiar with Octave's classes to comment on the merits implementation, but I like that the patch is short and simple.
|
Sun 07 Sep 2014 10:37:16 AM UTC, comment #10:
Hi,
I have attached a patch proposal in which I implemented a new class (pval_vector), based on std::vector< std::pair<std::string, octave_value> >. The type which is used to store default properties, pval_map_type, is redefined as a pval_vector instead of a std::map.
I reimplemented some of the std::map methods so that the type change doesn't affect much functions.
Can someone test the patch and eventually comment the approach?
(file #32040)
|
Mon 30 Jun 2014 03:11:16 PM UTC, comment #9:
Looks like I have underestimated this task: currently, the default values are stored in a std::map<std::string, octave_value>, which means that the order in which key/values are inserted is lost.
The only solution I can see is to replace this container by an octave_scalar_map or a custom class that keeps track of the order in which the values have been inserted (e.g. std::vector<std::pair<std::string, octave_value>>).
In any case this will involve many more changes than I had expected.
Does someone have another approach?
|
Thu 26 Jun 2014 10:46:39 AM UTC, comment #8:
The patch has never been pushed, and it is a good thing.
I had a look a few days ago to this bug and found that my approach was wrong: it makes octave behavior independent of the order in which the default properties have been set by the user (which doesn't match matlab behavior). I'll propose a neww patch in the coming days/week.
|
Thu 26 Jun 2014 10:16:11 AM UTC, comment #7:
I still see the bug. Is it possible that the patch never made it into the repository?
|
Mon 24 Feb 2014 09:12:27 AM UTC, comment #6:
Thanks Ben.
|
Mon 24 Feb 2014 01:57:59 AM UTC, comment #5:
Pantxo, I applied your patch. All tests in graphics.cc passed for me.
|
Sun 23 Feb 2014 09:40:54 PM UTC, comment #4:
Hello,
Ben, you are right the problem is in the order the properties are set.
The simplest way I found to solve this issue is to set the whole list of defaults (not that much) twice. It seems a bit hacky but I think it's robust.
Can someone try the attached patch?
Pantxo
(file #30681)
|
Mon 04 Mar 2013 01:55:33 AM UTC, comment #3:
Equivalent problem for axes objects.
|
Mon 04 Mar 2013 12:15:59 AM UTC, comment #2:
A second test that seems to confirm the "position" is set before the "units", and the changing the "units" triggers the updater.
I'm modifying the summary to to better indicate the problem.
|
Mon 04 Mar 2013 12:09:52 AM UTC, comment #1:
To help isolate the problem, I tried converting the figure's units to the coded default value of "pixels".
Without looking at the code, I guess that the the updaters for the figure's properties are active during the initialization process. I had thought the updaters were off (or should be) during the initialization process.
|
Fri 01 Mar 2013 12:26:40 PM UTC, original submission:
This code
shows that setting 'defaultfigureposition' has no effect. What I get is
ans =
-1.7857e-04 -9.5238e-04 1.7857e-04 2.8571e-04
(along with a tiny figure at the lower left corner).
I am using the dev tip f837bdd535f7 of Feb 14.
|