bugGNU Octave - Bugs: bug #35511, reset (h) function doesn't work at...


bug #35511: reset (h) function doesn't work at all

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Sun 12 Feb 2012 01:10:42 AM UTC  
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: NoneAssigned to: None
Originator Name: Ben AbbottOpen/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Tue 25 Mar 2014 02:25:36 PM UTC, comment #12:

I can take a look at bug #41770, but not until the weekend when I have some free time.

It seems logical to me to treat all graphics primitives the same way. If this means moving defaults into graphics.in.h that would be fine. There is already a BEGIN_PROPERTIES (patch) section in graphics.in.h so I suppose it would just mean extending it for any missing properties.

Rik <rik5>
Project Administrator
Mon 24 Mar 2014 05:13:28 PM UTC, comment #11:

Ben, addproperty doesn't seem to offer a way to restrict property access so I am not too concerned about that.

I am progressing on this bug. The approach I proposed in comment #3 works quite well for me but there are still some issues.

First, I would like to use factory defaults when they are defined. For this, it would help if someone could review the patch in bug #41770.

Second, "patch" updaters and default data are defined in _patch_.m. I think, as all other base graphics objects, patches should not rely on property listeners (but rather on update_xxx methods) and should have all their default properties defined in graphics.cc(or .in.h). Any comment?

Pantxo Diribarne <pantxo>
Sun 16 Mar 2014 10:58:29 PM UTC, comment #10:

Does addproperty() allow read-only properties to be created? If so would adding a read-only property to a figure cause an error?

Ben Abbott <bpabbott>
Project Member
Sun 16 Mar 2014 10:26:59 PM UTC, comment #9:

Hello Rik,
I proposed a patch to at least have a way to determine programmatically (by name) if a property is read-only (see bug #41629, first patch). Do you think it should be done differently? Are there limitations with this approach?

Pantxo Diribarne <pantxo>
Sun 16 Mar 2014 07:35:08 PM UTC, comment #8:

Pantxo, you're approach seems about right. I agree that it would be nice if there were a way to quickly remove the Read-Only properties rather than looking for the Read-Only properties by name. But I don't have any handy trick to do that.

Rik <rik5>
Project Administrator
Thu 20 Feb 2014 09:02:08 AM UTC, comment #7:

Thank you Ben, that is what I expected from the doc.
Now I'll wait for someone to validate (or not :-) my approach as described in comment #3 (and the patch I attached to show my intents).

As it will make a big changeset, I'd be happy to have a go-ahead.

Pantxo Diribarne <pantxo>
Wed 19 Feb 2014 03:50:47 PM UTC, comment #6:

Hi Pantxo,

Sorry for the delay, my Mac is dying a slow/intermittent death. If only it would give up its last breath I can get it replaced. In any event, it is working nicely for the moment. The window position after the second reset (). The result of your script is below.

Ben Abbott <bpabbott>
Project Member
Wed 19 Feb 2014 09:36:54 AM UTC, comment #5:

Hi Ben,

At the first reset did the figure jump back to its default position?

I put the expected result as comments. If I'm correct, now I need to know if the work flow I proposed is acceptable as a first approach and if I should proceed in that direction.

Pantxo Diribarne <pantxo>
Wed 19 Feb 2014 01:31:31 AM UTC, comment #4:

I ran the script below with Matlab R2013b

The resulting figures are attached.

(file #30604, file #30605)

Ben Abbott <bpabbott>
Project Member
Tue 18 Feb 2014 01:42:40 PM UTC, comment #3:

Dan, the default_properties attribute you are talking about, which only parent objects have (uitoolbar, root, figure, axes), is meant to store "local" defaults, i.e when you do:

The default property is stored in figure(1)'s default_properties and will apply only to its axes children. The mechanism works well and is based on the use of override_defaults function.

The static function (reset_default_properties) that is called by reset_default_properties methods is not doing anything useful and should be removed.

I have attached a proof of concept of what I think should be done by reset_default_properties methods. Basically the work flow is:
- local defaults must be emptied if they exist (parent objects only)
- reset all properties but read only and those that should not be reset according to matlab doc. This may be done in the method itself or via properties::set_defaults when it's defined
- override with parent defaults (except for root)

With this patch the following works as expected:

Can someone confirm this is the good interpretation/approach ?

(file #30595)

Pantxo Diribarne <pantxo>
Mon 10 Sep 2012 07:02:29 PM UTC, comment #2:

I believe the problem is on the "set" side of things, not the "reset" side. I've followed the code that does the reset and it appears to be run, but there isn't anything in the list of defaults. I've looked at the property_list "set" for the defaults, and that doesn't appear to happen. So whatever mechanism existed before for setting the defaults isn't happening.

Dan Sebald <sebald>
Tue 21 Feb 2012 10:15:01 PM UTC, comment #1:

Re-titling the report as the function behavior is much worse than expected. The embedded docstring does not match what Matlab says the function should do. Nor does the function appear to work for any sample property.

The linewidth should have been reset to 0.5.

Rik <rik5>
Project Administrator
Sun 12 Feb 2012 01:10:42 AM UTC, original submission:

The commands below should result in a plot whose color map is jet()

Ben Abbott <bpabbott>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #30604:  first reset.png added by bpabbott (48kB - image/png)
file #30605:  second reset.png added by bpabbott (48kB - image/png)
file #30595:  reset_poc_bug35511.patch added by pantxo (4kB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by pantxo (Updated the item)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by bpabbott (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Feb 2014 01:31:31 AM UTCbpabbottAttached File-=>Added first reset.png, #30604
      Attached File-=>Added second reset.png, #30605
    Tue 18 Feb 2014 01:42:40 PM UTCpantxoAttached File-=>Added reset_poc_bug35511.patch, #30595
    Tue 21 Feb 2012 10:15:01 PM UTCrik5Summaryreset(gcf) doesn\'t reset colormap to default=>reset (h) function doesn't work at all

    Back to the top

    Powered by Savane 3.1-cleanup