When setting the Data Browser preferences, and option to Show/Hide the Packages folder would be helpful. Alternatively, an option to display the Packages folder always at the top or bottom of the root folder list would be just as good.
I am not sure I understand why you want this: I can see that under some circumstances you might want to be able to hide data folders but I am not so sure there is much point of doing that in the Data Browser. After all, you can't really hide data folders from anyone userLevel>8 and for those below all you really need to do is close the Data Browser window which might provide sufficient obfuscation.
It actually gets a bit more complicated. Suppose you hide Packages in the Data Browser but that your procedures set the current data folder to Packages. What would you have the DB display as the current data folder under these circumstances? Where would the red arrow point?
I am not sure I understand why you want this: I can see that under some circumstances you might want to be able to hide data folders but I am not so sure there is much point of doing that in the Data Browser. After all, you can't really hide data folders from anyone userLevel>8 and for those below all you really need to do is close the Data Browser window which might provide sufficient obfuscation.
It actually gets a bit more complicated. Suppose you hide Packages in the Data Browser but that your procedures set the current data folder to Packages. What would you have the DB display as the current data folder under these circumstances? Where would the red arrow point?
I was using the Data Browser to jump manually between sets of data folders. Arranging them alphabetically lead to Packages being in the middle of data folder sets ... in other words, acting like it was a place where I could also look for my data. "Hmmm (I thought to myself) ... it would be better if `Packages` were not always showing up in the middle of this list as one of my potential data folders ... if it could somehow be `hidden` or just always sorted to the top or bottom ... so I can find folder pb001 immediately after folder pa001.".
Thus was a thought translated to a feature request.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
The annoyance I at times still face in browsing data folders is in the location of the Packages data folder when data folders are organized alphabetically. It appears in the middle of a list of actual data folders. As such, when searching/sorting visually through data folders in the browser, my mind just does not process to overlook it as easily as I would like.
The Package folder is a special data folder, not a true "data" folder. Could some thought be given perhaps to changing how the data browser handles it during sorting operations - for example having it "excluded" from the sorting to appear always at the top/bottom of the data folder list.
I hesitate to suggest also perhaps the adoption of a "." (dot) (ie .Packages) or equivalent notation that would both designate a given data folder as "special" and thereby also sort it to the top/bottom of the list automatically. Though having a useful basis in Unix, such an option is likely overkill when only where Packages data folder appears in the browser sorting is the annoyance.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
I also think of the Packages folder as a special folder and like to be able to access it "separately" from other folders. My usual solution is to keep the data folders in one (or more) root-level folder(s) called "data" (or "original" and "treated" etc.). I think starting folder names with a dot would imply changing the Igor naming rules at a very fundamental level and is therefore unlikely to happen.
...My usual solution is to keep the data folders in one (or more) root-level folder(s) called "data" (or "original" and "treated" etc.).
How this shows in the data browser is my only (minor) annoyance. I have an "easier" time getting to where I am always heading when the place that I consistently want to avoid is consistently in one place (the top), as in the second example below. Currently, no method exists to create this second case in the data browser in a consistently reliable way.
root
original
Packages
treated
root
Packages
original
treated
It is IMO analogous to the "annoyance" that someone from the Mac OS world (me) faces in using Windows and expecting a menu bar to be consistently at the top of the entire screen for ANY application.
harneit wrote:
I think starting folder names with a dot would imply changing the Igor naming rules at a very fundamental level and is therefore unlikely to happen.
Having folder designations that use "." is only a worthwhile option when tools are in place that make use of and indeed might require this nomenclature. One example is that such a designation will automatically sort .Packages always to the top of the data browser window during a sort by name option. Another is to have a button to show/hide "dot" datafolders option in the data browser.
I can also see the utility in having "." folders to populate experiments with "special" places to store such things as startup configuration files (.Startup), packages (.Packages), globals (.Globals), paths (.Paths), data backup (.Backups) .... much the same way as Unix stores such things in hidden "dot" files. A user such as you would then click an option in the data browser window to hide such "special" folders and be all the better able to see only the datafolders of importance to the work you have at hand.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
I am not sure I understand why you want this: I can see that under some circumstances you might want to be able to hide data folders but I am not so sure there is much point of doing that in the Data Browser. After all, you can't really hide data folders from anyone userLevel>8 and for those below all you really need to do is close the Data Browser window which might provide sufficient obfuscation.
It is really for my use, not others, in a way that I have explained a bit better now I hope. I see the Data Browser as a way for me to move visually through my different data sets, not as a way to program for others to watch how a procedure moves (the red arrow) through different data folders.
Igor wrote:
It actually gets a bit more complicated. Suppose you hide Packages in the Data Browser but that your procedures set the current data folder to Packages. What would you have the DB display as the current data folder under these circumstances? Where would the red arrow point?.
Well, again, I do actually not visualize myself using a procedure to move the red arrow around in the (open) Data Browser window in any intentioned manner for data analysis (ie, debugging the operation of a procedure is a separate issue). My intentioned moves of the red arrow in the Data Browser are manually done.
As an answer to this question though, I would suggest, when "dot" data folders are "hidden", that a call to SetDataFolder root:.Packages would cause the red arrow in the Data Browser to point to "root" and turn gray (or something such), signaling visually to anyone so intent that it is currently pointing to a data folder otherwise "hidden" at the root level or lower. It is much the same as what currently happens with a call to SetDataFolder root:data:dataset01 would be made while the Data Folder "root:data" is in its unexpanded visual state in the Data Browser.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
From what I understand you just want to be able to get the Packages data folder "visually out of your way" while moving around data or data folders that contain "real data". For this purpose, you propose to introduce a unix-like convention (dot-folder names). This seems a bit of a radical solution in view of your statement that the present state is "a minor bother" to you: just think that the rest of the world would have to adhere to your scheme, and that possibly many packages that rely on the current convention could be broken. I just don't see that happening.
With my earlier proposal, I meant that if you use a convention like putting all "real" data folders into a top-level folder called "data", you can then double-click on the "data" folder and all other folders bothering you visually just disappear (at least that's what happens on windows). You're then free to do all your shuffling.
Alternatively, if you so like the dot-idea, I propose the following snippet:
Menu"Macros" "Weimerize Data Browser" "UnWeimerize Data Browser" End
function/S MyDotFolderList() return"Packages;Settings"// change this to according to your needs end
function DataBrowserIsOpen() return!!strlen(GetBrowserSelection(-1))// return 1 if open, else 0 end
function WeimerizeDataBrowser() if( DataBrowserIsOpen()) Execute/Q/Z"ModifyBrowser echoCommands = 0"
DoDotFolders(1) else DoAlert1, "There is currently no DataBrowser that I could weimerize.\rShould I open one for you?" if( V_Flag == 1) Execute"CreateBrowser"
WeimerizeDataBrowser() endif endif end
function DoDotFolders(show) variable show string dotFolders = MyDotFolderList(), dotFolderName variable n if( show == 1) for( n = 0; n <ItemsInList(dotFolders); n += 1)
dotFolderName = StringFromList(n, dotFolders) if(DataFolderExists("root:"+dotFolderName)&!DataFolderExists("root:'."+dotFolderName+"'")) RenameDataFolder root:$dotFolderName, $("."+dotFolderName) endif endfor Execute/Q/Z"ModifyBrowser deleteUserButton=DOTs" Execute/Q/Z"ModifyBrowser appendUserButton={NoDOTs, \"DoDotFolders(0)\", 1}" else for( n = 0; n <ItemsInList(dotFolders); n += 1)
dotFolderName = StringFromList(n, dotFolders) if(DataFolderExists("root:'."+dotFolderName+"'")&!DataFolderExists("root:"+dotFolderName)) RenameDataFolder root:$("."+dotFolderName), $dotFolderName endif endfor Execute/Q/Z"ModifyBrowser deleteUserButton=NoDOTs" Execute/Q/Z"ModifyBrowser appendUserButton={DOTs, \"DoDotFolders(1)\", 1}" endif end
function UnWeimerizeDataBrowser()
DoDotFolders(0) Execute/Q/Z"ModifyBrowser deleteUserButton=DOTs" Execute/Q/Z"ModifyBrowser echoCommands = 1"// possibly comment this out if you prefer no-echo mode end
This renames your favorite folders (see function MyDotFolderList()) to dot-folders temporarily and appends an extra button to your Data Browser. Press the "NoDOTs" button to undo. The button is dynamically renamed. Note that renaming folders in this way automatically sorts them at the top of the Data Browser when you have set its Preferences to "sort by name" or to "sort by name and type". Your code (and any other Package'd code) will probably be broken while in "dot-mode".
I might just need to copy this snippet to my pending faculty activity report to show the level of notoriety (or perhaps infamy) my postings are raising :-)
In all seriousness, my suggestion of having a dot notation is predicated on having a clear utility for such a notation, and the thoughts about such were just that ... thoughts. I certainly have no desire to force a dot notation and then ask for fixes to other issues that this would cause. As such, a reasonable fix to my Data Browser sorting annoyance would be to have a check box in the Preferences dialog menu that sets/unsets the Packages Data Folder to stay at the top during any sorting operations. I will also certainly try out this code snippet, as it looks to do exactly that (and the "user beware" warnings are all fully understood).
Oh, and I now also better understand your suggestion to put important data folders into one common subfolder and then "step in to" that folder as a way to "hide" things above. I see how from this that a top-level naming convention for folders akin to Packages, data, globals, preferences .... would resolve my annoyance too (all without dots).
Thanks!
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
It actually gets a bit more complicated. Suppose you hide Packages in the Data Browser but that your procedures set the current data folder to Packages. What would you have the DB display as the current data folder under these circumstances? Where would the red arrow point?
A.G.
WaveMetrics, Inc.
April 28, 2009 at 11:03 am - Permalink
I was using the Data Browser to jump manually between sets of data folders. Arranging them alphabetically lead to Packages being in the middle of data folder sets ... in other words, acting like it was a place where I could also look for my data. "Hmmm (I thought to myself) ... it would be better if `Packages` were not always showing up in the middle of this list as one of my potential data folders ... if it could somehow be `hidden` or just always sorted to the top or bottom ... so I can find folder pb001 immediately after folder pa001.".
Thus was a thought translated to a feature request.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
April 28, 2009 at 01:06 pm - Permalink
The annoyance I at times still face in browsing data folders is in the location of the Packages data folder when data folders are organized alphabetically. It appears in the middle of a list of actual data folders. As such, when searching/sorting visually through data folders in the browser, my mind just does not process to overlook it as easily as I would like.
The Package folder is a special data folder, not a true "data" folder. Could some thought be given perhaps to changing how the data browser handles it during sorting operations - for example having it "excluded" from the sorting to appear always at the top/bottom of the data folder list.
I hesitate to suggest also perhaps the adoption of a "." (dot) (ie .Packages) or equivalent notation that would both designate a given data folder as "special" and thereby also sort it to the top/bottom of the list automatically. Though having a useful basis in Unix, such an option is likely overkill when only where Packages data folder appears in the browser sorting is the annoyance.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
April 19, 2010 at 09:39 am - Permalink
Wolfgang Harneit
April 22, 2010 at 11:51 am - Permalink
How this shows in the data browser is my only (minor) annoyance. I have an "easier" time getting to where I am always heading when the place that I consistently want to avoid is consistently in one place (the top), as in the second example below. Currently, no method exists to create this second case in the data browser in a consistently reliable way.
original
Packages
treated
Packages
original
treated
It is IMO analogous to the "annoyance" that someone from the Mac OS world (me) faces in using Windows and expecting a menu bar to be consistently at the top of the entire screen for ANY application.
Having folder designations that use "." is only a worthwhile option when tools are in place that make use of and indeed might require this nomenclature. One example is that such a designation will automatically sort .Packages always to the top of the data browser window during a sort by name option. Another is to have a button to show/hide "dot" datafolders option in the data browser.
I can also see the utility in having "." folders to populate experiments with "special" places to store such things as startup configuration files (.Startup), packages (.Packages), globals (.Globals), paths (.Paths), data backup (.Backups) .... much the same way as Unix stores such things in hidden "dot" files. A user such as you would then click an option in the data browser window to hide such "special" folders and be all the better able to see only the datafolders of importance to the work you have at hand.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
April 22, 2010 at 01:46 pm - Permalink
It is really for my use, not others, in a way that I have explained a bit better now I hope. I see the Data Browser as a way for me to move visually through my different data sets, not as a way to program for others to watch how a procedure moves (the red arrow) through different data folders.
Well, again, I do actually not visualize myself using a procedure to move the red arrow around in the (open) Data Browser window in any intentioned manner for data analysis (ie, debugging the operation of a procedure is a separate issue). My intentioned moves of the red arrow in the Data Browser are manually done.
As an answer to this question though, I would suggest, when "dot" data folders are "hidden", that a call to SetDataFolder root:.Packages would cause the red arrow in the Data Browser to point to "root" and turn gray (or something such), signaling visually to anyone so intent that it is currently pointing to a data folder otherwise "hidden" at the root level or lower. It is much the same as what currently happens with a call to SetDataFolder root:data:dataset01 would be made while the Data Folder "root:data" is in its unexpanded visual state in the Data Browser.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
April 22, 2010 at 01:44 pm - Permalink
From what I understand you just want to be able to get the Packages data folder "visually out of your way" while moving around data or data folders that contain "real data". For this purpose, you propose to introduce a unix-like convention (dot-folder names). This seems a bit of a radical solution in view of your statement that the present state is "a minor bother" to you: just think that the rest of the world would have to adhere to your scheme, and that possibly many packages that rely on the current convention could be broken. I just don't see that happening.
With my earlier proposal, I meant that if you use a convention like putting all "real" data folders into a top-level folder called "data", you can then double-click on the "data" folder and all other folders bothering you visually just disappear (at least that's what happens on windows). You're then free to do all your shuffling.
Alternatively, if you so like the dot-idea, I propose the following snippet:
"Weimerize Data Browser"
"UnWeimerize Data Browser"
End
function/S MyDotFolderList()
return "Packages;Settings" // change this to according to your needs
end
function DataBrowserIsOpen()
return !!strlen(GetBrowserSelection(-1)) // return 1 if open, else 0
end
function WeimerizeDataBrowser()
if( DataBrowserIsOpen() )
Execute/Q/Z "ModifyBrowser echoCommands = 0"
DoDotFolders(1)
else
DoAlert 1, "There is currently no DataBrowser that I could weimerize.\rShould I open one for you?"
if( V_Flag == 1 )
Execute "CreateBrowser"
WeimerizeDataBrowser()
endif
endif
end
function DoDotFolders(show)
variable show
string dotFolders = MyDotFolderList(), dotFolderName
variable n
if( show == 1 )
for( n = 0; n < ItemsInList(dotFolders); n += 1 )
dotFolderName = StringFromList(n, dotFolders)
if( DataFolderExists("root:"+dotFolderName) & !DataFolderExists("root:'."+dotFolderName+"'") )
RenameDataFolder root:$dotFolderName, $("."+dotFolderName)
endif
endfor
Execute/Q/Z "ModifyBrowser deleteUserButton=DOTs"
Execute/Q/Z "ModifyBrowser appendUserButton={NoDOTs, \"DoDotFolders(0)\", 1}"
else
for( n = 0; n < ItemsInList(dotFolders); n += 1 )
dotFolderName = StringFromList(n, dotFolders)
if( DataFolderExists("root:'."+dotFolderName+"'") & !DataFolderExists("root:"+dotFolderName) )
RenameDataFolder root:$("."+dotFolderName), $dotFolderName
endif
endfor
Execute/Q/Z "ModifyBrowser deleteUserButton=NoDOTs"
Execute/Q/Z "ModifyBrowser appendUserButton={DOTs, \"DoDotFolders(1)\", 1}"
endif
end
function UnWeimerizeDataBrowser()
DoDotFolders(0)
Execute/Q/Z "ModifyBrowser deleteUserButton=DOTs"
Execute/Q/Z "ModifyBrowser echoCommands = 1" // possibly comment this out if you prefer no-echo mode
end
This renames your favorite folders (see
function MyDotFolderList()) to dot-folders temporarily and appends an extra button to your Data Browser. Press the "NoDOTs" button to undo. The button is dynamically renamed. Note that renaming folders in this way automatically sorts them at the top of the Data Browser when you have set its Preferences to "sort by name" or to "sort by name and type". Your code (and any other Package'd code) will probably be broken while in "dot-mode".Best regards,
Wolfgang
April 23, 2010 at 01:48 pm - Permalink
LOL
I might just need to copy this snippet to my pending faculty activity report to show the level of notoriety (or perhaps infamy) my postings are raising :-)
In all seriousness, my suggestion of having a dot notation is predicated on having a clear utility for such a notation, and the thoughts about such were just that ... thoughts. I certainly have no desire to force a dot notation and then ask for fixes to other issues that this would cause. As such, a reasonable fix to my Data Browser sorting annoyance would be to have a check box in the Preferences dialog menu that sets/unsets the Packages Data Folder to stay at the top during any sorting operations. I will also certainly try out this code snippet, as it looks to do exactly that (and the "user beware" warnings are all fully understood).
Oh, and I now also better understand your suggestion to put important data folders into one common subfolder and then "step in to" that folder as a way to "hide" things above. I see how from this that a top-level naming convention for folders akin to Packages, data, globals, preferences .... would resolve my annoyance too (all without dots).
Thanks!
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
April 23, 2010 at 04:32 pm - Permalink