Default "Open" Directory in PI 1.8.04.1195 OSX

[Ken_sturrock]

My images are kept several layers deep on a remote server.

Previously, PI seemed pretty good about remembering the last path I used so if I, for example, used File/Open or the Subframe Selector Script, PI would return me to the directory where my files are kept the next time I used the command.

Since upgrading to 1.8.04.1195, PI is enamored with my "documents" directory instead. So, I'll load images up into the Subframe Selector Script and sort the files. When I clear the list and add new files, I'm back to ~/Documents and I have to change servers and dig the appropriate directory out again. The same thing will happen for the next iteration. It is not a huge deal but, by the 20th time in a session, it does get a bit old.

I can always pick the directory from the "shortcut" drop menu in the "File Open" dialog box, but am I missing something obvious?

Thanks.

[Juan Conejero]

This issue has already been reported in one occasion, but we can't reproduce it. File open/save folders are always remembered correctly on our testing OS X machines, including both OS X 10.10.5 and 10.11.2.

[Ken_sturrock]

Thank you, Juan.

I went back to 1.8.03 and found that the open dialog box will open my ~/Documents but will then switch itself to the last folder that was used, while 1.8.04 will stay in ~/Documents.

I have temporarily moved back to 1.8.03. I have over a thousand images that I need to calibrate and, in addition to the directory location issue, my file management scripts are still setup for files with a FIT extension. I also found that 1.8.03 was about four times faster at calibrating than 1.8.04 on my old Macintosh (running 10.10).

I'll make the jump to 1.8.04 when I upgrade computers later in the year.

All the best.

[pfile]

ken, can you test that you can search for "fit" or "fits" in 1.8.04.1195, in a directory where you know there are fits files below? if i do this on either of my machines, no files are found.

rob

[dmcclain]

I just had an incident, after struggling with the same issue all day (and has been frustrating since installation some weeks ago), where PI hung and I forcibly killed the running process. On restart, it initially acts the way it used to behave, where it remembers the locations of my data files. It may not last.... but to me, this indicates the kind of error situation arising from an uninitialized variable. The result would be a randomly appearing error state. That could explain why Juan cannot reproduce the error on his systems.

[Ken_sturrock]

Rob: If I understand your question, then yes. When I use the open dialog box, I can see FIT files as well as XISF files in the same directory.

The odd thing is that when I started up 1.8.04 to test your question, I found that PI was now remembering the PARENT of the last directory that I was in and that this PARENT directory was opened automatically by the file open dialog box. I then quit PI and restarted it to find that it would now list the LAST directory used in the path field (with PI/non-native open dialog boxes) but listed no files or sub-directories and refused to change directories. The dialog box was dead.

I rebooted and found that PI then remembered the LAST directory that I used and it worked as expected.

So, there is something squirrelly happening here.

Changing between native/non-native dialog box styles didn't make a difference.
 

[pfile]

no - what i meant is that if you were to say, go up one level in the file browser, and then type "fit" or "fits" in the search box, do you get any results?

i don't have any problem choosing fits files, but i can't search for them. despite there definitely being fits files below the directory i'm searching in, they are never found by the search in the "open file..." dialog.

i'm asking in this thread because it seems there are some weird behaviors with native file dialogs going on...

rob

[Ken_sturrock]

Thanks, Rob, I see what you mean.

No. I can't find a fit or an xisf file from the parent, or even the same, directory using the PI file/open dialog box the way that I can from a finder window. I tried it several ways and closed the dialog box. When I reopened the file/open dialog, I was back in ~/Documents.

Oh well....

[dmcclain]

I think I may have found the answer.... Down in the local Library folder is a PixInsight folder that contains some plist files. I tried renaming the file folder to PixInsightx so that it wouldn't be found on the next startup. PI recreates the folder for itself on the next startup, and by golly... the problem went away.

So apparently Juan was correct about "some setting not being right in my system" - the old leftover plist files from a previous version were probably not right.

[dmcclain]

... oh well... it was good while it lasted. But about an hour into processing the forgetful behavior returned. But at least maybe this is a hint for the developers.

[Juan Conejero]

We have tried to reproduce this problem many times. After hours of intensive work with PixInsight 1.8.4 on OS X, folders are always remembered without problems on our machines. I can't solve a problem if I can't understand it, and except in trivial cases, being able to reproduce it consistently is a prerequisite.

From your previous post, it seems that performing a full reset of application settings fixed the issue. This should provide a hint. Are you running any utilities on your Mac that could be messing with configuration files in the background, such as virus protection software for example?

[dmcclain]

NADA! PI is the only thing running on the Mac (OSX 10.10.5 Yosemite), apart from all the junk that Apple has running in daemons. This was a virgin install of a new Mac Mini (obtained last August, but only unboxed yesterday).

The situation honestly looks like you upgraded the underlying OS-independent framework in the latest release, and that framework may be failing to properly initialize some state values. As such, what you get depends on a random collection of system environment, and it may fail for some people and not for others.

.. or else, the framework subtly changed some calling protocol on the file handling dialogs.

... thinking further along, since the system more or less works properly when using the Linux-style dialogs, and fails when using native-style on the Mac, that leads me to suspect an error in the framework implementation of OSX dialog handling.

[dmcclain]

I just had a long look at the PCL made available on GitHub, and at the Qt documentation on file dialogs. Interesting read, tons of stuff to manipulate. But the distance between the PCL interface and the Qt interface is so large, it appears that you are holding some cards close to your vest. Hence, you become the responsible party... you have my condolences.

But while down in the PCL repository, I noticed a tool called ExternalToolProcess. Very nice if we could have that one!

I can see that PI has grown, organically, over time. And it is very nice. I hate to be a heretic, but there are even wider issues with environment and history management that can only be solved with a rework of logic. Example, saving files has no knowledge of the last opened file and will store your images in a possibly unrelated folder if you aren't careful about the workflow.

..I'm not suggesting that open-file dialogs correspond with the environment in a manner that save-as-file dialogs would respond. The situation is more complicated than that. A simple band-aid solution would be to have some kind of project setting, so that when we switch to processing a different stack, we can tell the system to focus where those files reside. But this requires deeper thought for a proper solution.

But I'm thinking of extending PI capabilities; have a look at this presentation PDF that I gave back in 2009(?) in Hamburg at the ECLM:

http://weitz.de/eclm2009/GigaDSP%20presentation.pdf

The block diagram pipelined approach would argue against any involvement with the file system, except for sources, sinks, and tees. All the rest would depend on an executive buffer manager to issue new image buffers on demand, allow them to evaporate when no longer useful, and let the buffer manager work with the file system / VM manager / cache system. Blocks would be oblivious.

[johnpohollaren]

I am seeing this same error in OSX with my Mac Pro using PixInsight 01.08.04.1195 Ripley (x64)

Is it possible to set a setting for an OS X Project that is the "Default Path" variable? Aka, every open/add file operation would start from $PIX_PATH?

Here's what I'm seeing:

• When I go "Open" a file, or "Add Files" in a Process, about 75% of the time, it will take me a few directory levels too high up and go to Documents.
• About 25% of the time, It will take me one level higher up than the a recent file I opened. However, it's not always the last file I opened. For example, sometimes it's from a light_calibrated_cc_reg folder from a project I was working on last week.

Per the suggestions in this thread, I have tried

• Removing the PixInsight folder from my local Library folder. It was regenerated on the next run. However, same behavior.
• Checking to make sure all .fits and .xifs files are not present in ~/Documents.

Attached as "Pic1_AddFileDialog" is what I usually see when I click on an Open or Add File dialog: e.g. ~/Documents
Attached as "Pic2_WhereMyProjectIs" is where my project file, and all my recently opened files are: e.g. ~/Documents/processed_photos/2016_02_08/flame_and_horsehead/

Here is the System Profiler information for the system I am using.

Hardware Overview:

  Model Name:   Mac Pro
  Model Identifier:   MacPro6,1
  Processor Name:   Quad-Core Intel Xeon E5
  Processor Speed:   3.7 GHz
  Number of Processors:   1
  Total Number of Cores:   4
  L2 Cache (per Core):   256 KB
  L3 Cache:   10 MB
  Memory:   64 GB
  Boot ROM Version:   MP61.0116.B15
  SMC Version (system):   2.20f18
  Illumination Version:   1.4a6
 
System Software Overview:

  System Version:   OS X 10.10.4 (14E46)
  Kernel Version:   Darwin 14.4.0
  Boot Volume:   Macintosh HD
  Boot Mode:   Normal
  Secure Virtual Memory:   Enabled
  Time since boot:   8 days 7:31

[dmcclain]

Honestly, from all my long experience in programming systems, this behavior is not controlled by OS X. Rather, OS X defines a collection of "well-known" locations that can be used by an application to load / store various settings it may need -- standard locations for documents, standard locations for program settings, etc.

This behavior is controlled by the Framework in use. In this case, QT5. I suspect that previous versions of PI used a previous version of QT that had been wrung out sufficiently for it to seem pleasant to operate. But QT5 is a major revision, and it appears it needs some more wringing out.

Not a PI problem, per se, but inherited from QT.

For now, a partial solution is to use non-native File Dialogs. The Linux-style dialogs do a better job (not quite correct either), but won't keep sending you back to Documents.