MathGroup Archive 2002

[Date Index] [Thread Index] [Author Index]

Search the Archive

RE: RE: RE: RE: Installing package "SpreadOption`"

  • To: mathgroup at smc.vnet.net
  • Subject: [mg35857] RE: [mg35852] RE: [mg35826] RE: [mg35699] RE: [mg35673] Installing package "SpreadOption`"
  • From: "DrBob" <majort at cox-internet.com>
  • Date: Sun, 4 Aug 2002 06:00:09 -0400 (EDT)
  • Reply-to: <drbob at bigfoot.com>
  • Sender: owner-wri-mathgroup at wolfram.com

Depending on what Zip utility you're using, yes, you can save the file
structure.  I can do this with PowerDesk, and I used to do it with PKZIP
and LHARC.  You'd use "relative paths" to save the DrawGraphics
directory, for instance, which (if I'm understanding the instructions
below) would contain FrontEnd\Palettes, FrontEnd\StyleSheets and
English\Documentation.  Then you'd unzip that file into the Applications
folder.  When you unzip, there's again an option... to keep or discard
paths.  You'd keep them, of course.

Bobby

-----Original Message-----
From: David Park [mailto:djmp at earthlink.net] 
To: mathgroup at smc.vnet.net
Subject: [mg35857] [mg35852] RE: [mg35826] RE: [mg35699] RE: [mg35673] Installing
package "SpreadOption`"

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

--------------------------------------------------------------






  • Prev by Date: Re: Mathematica to QuickTime Movie Player Questions
  • Next by Date: undocumented assumption in limit
  • Previous by thread: RE: RE: RE: RE: Installing package "SpreadOption`"
  • Next by thread: Re: Installing package "SpreadOption`"