RE: RE: RE: Installing package "SpreadOption`"
- To: mathgroup at smc.vnet.net
- Subject: [mg35852] RE: [mg35826] RE: [mg35699] RE: [mg35673] Installing package "SpreadOption`"
- From: "David Park" <djmp at earthlink.net>
- Date: Sat, 3 Aug 2002 00:17:25 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
Thank you for your detailed reply. I tried out your method with a documented package I have that has a style sheet and a palette. It worked as advertised and I agree that your method is a perfectly reasonable and good method. So, now I would say that there are two good methods. They differ mainly in where users would prefer to store various file types. Let me outline them along with their advantages and disadvantages, which are relatively minor and a matter of taste. (I have a question about using zip files that somewhat affects the advantages and disadvantages.) 1) Gather all the package material together in one folder, which is placed in the Applications folder. Create subfolders FrontEnd\Palettes, FrontEnd\StyleSheets and English\Documentation for those items if they exist. The advantage is that all the package material is in one place. The disadvantage is that you have packages, palettes and style sheets scattered all over. 2) Put the package and documentation in a folder in the ExtraPackages directory. Put any palettes in Configuration\FrontEnd\Palettes. Put any style sheets in Configuration\FrontEnd\StyleSheets. The advantage is that you have all your third party packages in one place, all your style sheets in one place and all your palettes in one place. The disadvantage is that the user must move the palettes and style sheets to the stanard directories. Now, I would like to ask you how I can send a package, style sheets, palettes and documentation to a user. I am working in Windows 98 and have the WinZip program. As far as I understand (and I did ask the WinZip people about it) it is not possible to include a file structure in a .zip file. You can make self-extracting zip files (which I don't know how to do) but I understood that only people working under Windows can use them. So at present, in my major package, I tell people how to set up the file structure in ExtraPackages. I put all the documentation files in one .zip file and all the package files plus the palette in a second .zip file. They have to copy them out into the correct folders. How can I send the files in a folder structure? If I can't do that, the first method loses a little of its appeal. 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 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 --------------------------------------------------------------