#86 after Save As..., the path remains at the location

open
nobody
puredata (321)
5
2011-06-01
2006-10-06
No

If you open an instance of an abstraction, then Save
As... to somewhere else, the path of that abstraction
stays at the original location, even though the file
was saved to the new location. Clicking File->Save
will then save to the original location rather than the
new location.

Tested on Mac OS X with Pd-0.39.2,
Pd-0.39.2-extended-test5, and Pd-0.40-0.

Discussion

  • Frank Barknecht

    Frank Barknecht - 2006-10-07

    Logged In: YES
    user_id=569446

    I'm note sure if that's a bug, though I agree, that it's
    confusing. But if you open an instance of an abstraction and
    save that under a different name, this action doesn't affect
    the name of the abstraction's instance as it is used in the
    parent patch: This one will stay the same. If you want to
    use your newly saved abstraction you need to rename the
    instance to the new name as well first.

     
  • Hans-Christoph Steiner

    Logged In: YES
    user_id=27104

    "Save As..." means write out a new file. A new file means a
    new class. The instance that started this process remains
    the old class, therefore is no longer related to this new class.

    This means its inconsistent to have this instance remain as
    the original class.

    Also, from a usability perspective, it makes things much
    more coherent. In every other app that I use, when I do
    "Save As...", that current view changes to the new file. It
    does not remain on the old file.

     
  • Hans-Christoph Steiner

    Logged In: YES
    user_id=27104
    Originator: YES

    Strange, I looked into this. It seems that just the title bar isn't being updated, but the patch does think of itself in the new location. [getdir] will show the new location. It seems that when canvas_rename() is called inside of canvas_savetofile(), the directory is not yet updated, when things get to canvas_reflecttitle(), and therefore canvas_getdir() returns the old location rather than the new one. Since this is now cosmetic, I'll leave it for another day.

     
  • Hans-Christoph Steiner

    • priority: 5 --> 2
    • status: open --> open-later
     
  • IOhannes m zmölnig

    confirmed with Pd-vanilla 0.42 (OSX) and 0.43 (linux)

    note that as soon as you edit the patch, the path get's updated to show the correct (new) one.

     
  • IOhannes m zmölnig

    • milestone: 594774 --> 1022526
    • assigned_to: nobody --> millerpuckette
    • status: open-later --> open-fixed
     
  • IOhannes m zmölnig

    looking through the sources, the problem is:
    canvas_rename() calls canvas_reflectttitle() just before the directory is set. so the old directory is shown (reflected)

    attached patch (against todays git) reverses the order, so when canvas_reflecttitle() is called, the directory is already set to the new value.

     
  • IOhannes m zmölnig

    • milestone: 1022526 -->
    • labels: 680482 --> 680704
     
  • IOhannes m zmölnig

    • milestone: --> 445837
     
  • Hans-Christoph Steiner

    • priority: 2 --> 5
    • assigned_to: millerpuckette --> nobody
    • labels: 680704 --> puredata
    • milestone: 445837 -->
    • status: open-fixed --> open
     
  • Hans-Christoph Steiner

    This patch did not change the behavior for me on the HEAD of pure-data.git, testing on Mac OS X 10.5.8. I opened an instance of myabs.pd in testpatch.pd from my Desktop, then save-as to /tmp/. Then I pressed Save again:

    saved to: /private/tmp/myabs.pd
    saved to: /Users/hans/Desktop/myabs.pd

    The first one is the Save-As, the second is the Save.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks