Re: RE: RE: Installing package "SpreadOption`"
- To: mathgroup at smc.vnet.net
- Subject: [mg35848] Re: [mg35826] RE: [mg35699] RE: [mg35673] Installing package "SpreadOption`"
- From: Omega Consulting <omega_consulting at yahoo.com>
- Date: Sat, 3 Aug 2002 00:17:01 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
At 01:42 AM 8/2/2002, David Park wrote:
>I am glad that some discussion of this is being generated.
>
>In general I disagree with your recommendation. If palettes and StyleSheets
>go along with a package, why not put them in Configuration\FrontEnd\Palettes
>and Configuration\FrontEnd\StyleSheets, which seem to be the places made for
>them? Then they automatically appear in the menu listings. (And you as a
>package writer would also know where to expect to find them.)
This is true for packages in the Applications directory as well, as long as
you put the files in the correct location inside the package. The advantage
to this layout, instead of what you propose, is that all files are stored
under the same directory tree. You can zip/tar/hqx a package and send it
off to someone. They just unpack it drop it in to their copy of Mathematica.
>I am not certain if I completely understand your approach and would
>appreciate further explanation. If you have a set of packages, stylesheets,
>palettes and documentation, where precisely would you put them? At the top
>level of the Applications directory? Or would you put them in a subdirectory
>within the Applications folder? If they are in a subdirectory, will
>Mathematica automatically find them? What if you want to call them from
>another subdirectory in the Applications folder? What about having several
>documentation folders for different packages? Can you have two
>Documentation\English folders in one directory? I don't think so. Suppose
>you provide a package with documentation and I supply a package with
>documentation. Is the user supposed to merge the BrowserCatergories files
>together? Would he know how to do it?
All of these are possible. Mathematica has a drop-in system as long as you
understand the layout scheme (which is a bit complicated, but worth
understanding). The trick is that each package gets its own directory.
Avoiding the conflicts you describe above.
All these properties are set by options, so let's look at an option:
In[3]:=
pp=PalettePath/.Options[$FrontEnd, PalettePath];
Let's just look at one value, the others are similar.
In[5]:=
pp[[6]]
Out[5]=
FrontEnd`FileName[{$TopDirectory,AddOns,Applications,_,FrontEnd,Palettes},
CharacterEncoding\[Rule]WindowsANSI]
This says look in $TopDirectory/AddOns/Applications for directories of any
name. Then in those directories look for a FrontEnd/Palettes directory with
*.nb files. If any of these files exist, when the front end is started,
then it will be included in the Palettes menu.
Similar things are done for StyleSheetPath and AddOnHelpPath (for
documentation). There are also other more exotic paths like
ConfigurationPath and SpellingDictionariesPath, but these are largely unused.
So when I write a package it looks like this:
MyPackageName/
MyPackages.m (Actual packages)
Kernel/
init.m (Stub package. Loaded by <<MyPackageName`)
FrontEnd/
Palettes/
MyPalettes.nb (Palettes)
StyleSheets/
MyStyleSheets.nb (Stylesheets)
Documentation/
$Language/ (English, French, Japanese, etc.)
BrowserCategories.m (Organization of docs)
BrowserIndex.nb (Master Index entries)
HelpFiles.nb (Actual documentation)
Just drop the whole tree into the $TopDirectory/AddOns/Applications
directory (a couple other directories work as well) and you're ready to go.
(Except you have rebuild the help index, but otherwise you're set.)
>In providing software to a user, I think it is a great advantage if the user
>does not have to specify or alter any paths. That may be simple for you, but
>it is a major hurdle to many users. If one puts the various objects in the
>places that WRI provided for them, it is never neccessary to specify paths.
I completely agree. I can't count the number of headaches I've had with
Mathematica packages that ask you to first do this and then do that. If
people knew about (i.e if it was well-documented) and used the default
directories, it would save us all a bunch of headaches.
>(Perhaps you want some commands in your package to automatically open a
>palette. If the palette has been placed in Configuration\FrontEnd\Palettes,
>you as the programmer can automatically write the path to open it. The user
>shouldn't have to worry about it. And he could also open the palette from
>the menu.)
There are a couple of way to do this.
1) The default NotebookPath option (which controls NotebookOpen) includes
all the directories in the default PalettePath. So you can do
NotebookOpen["MyPalette.nb"]
2) Or you could actually search the $Path
fns = FileNames[
ToFileName[{"MyPackage", "FrontEnd", "Palettes"}, "MyPalette.nb"], $Path
];
If[fns=!={}, NotebookOpen[First[fns]]]
Sometimes I prefer the later in case the user installed in a non-standard
location.
>I don't claim to be the greatest expert on this subject. I would be glad to
>learn more. But, so far, all the arguments I have heard for putting packages
>somewhere other than an ExtraPackages subfolder have been unconvincing to
>me.
>
>David Park
>djmp at earthlink.net
>http://home.earthlink.net/~djmp/
>
>
>From: Omega Consulting [mailto:omega_consulting at yahoo.com]
To: mathgroup at smc.vnet.net
>
>ExtraPackages is a fine place to put packages if your package consists
>solely of *.m files.
>
>However, in general I would recommend the Applications directory. The front
>end has its own sets of paths (for finding palettes, stylesheets, and
>documentation). With the default settings, the front end looks in the
>Applications and Autoload directories, not the ExtraPackages directory.
>
>--------------------------------------------------------------
>Omega Consulting
>"The final answer to your Mathematica needs"
>
>Spend less time searching and more time finding.
>http://www.wz.com/internet/Mathematica.html
--------------------------------------------------------------
Omega Consulting
"The final answer to your Mathematica needs"
Spend less time searching and more time finding.
http://www.wz.com/internet/Mathematica.html