Yes, I used Linux. I thought that perhaps the // dirsep would work on Windows too. It matters whether TEMP is set, as an OS environment variable, to a writable directory. If not set then Temp must be a directory in your homedir, as the code is written. The cat(TEMPDIR,"PrimeBack.jpg") is the location that the image file will be written out to, when the initproc procedure gets run. The location "files//PrimeBack.jpg" was simply the source location, relative to currentdir when I actually ran all that code to create the .mla file. Those two locations, then, aren't related. The initproc is just three steps. The first is to find a temp directory and write out the image file (storing that location). The second is to use that location, and invoke the Maplet which uses that image file. The third is to delete that unpacked image file. Naturally, I realize that you'll have seen all that. I didn't really know much about LibraryTools:-ActivationModule before now. It seems a useful thing to learn. acer

This can be done using an .mla and LibraryTools:-ActivationModule() directly.

try FilesTools:-Remove(".//SimpleTest.mla"); catch: end try:
LibraryTools:-Create(".//SimpleTest.mla");
march('addfile', ".//", "files//PrimesBack.jpg", "SimpleTest.mla");
                                                                                                                                           
initproc:=proc()
local maplet, TEMPDIR, found, x, IMAGELOC;
    TEMPDIR := getenv(TEMP);
    if not (TEMPDIR<>"" and FileTools:-Exists(TEMPDIR)=true
            and FileTools:-IsDirectory(TEMPDIR)=true) then
        TEMPDIR:=cat(kernelopts(homedir),"//Temp//");
        if not (TEMPDIR<>"" and FileTools:-Exists(TEMPDIR)=true
                and FileTools:-IsDirectory(TEMPDIR)=true) then
           error "unable to find directory for temp files";
        end if;
    end if;
    for x in libname do
        try
            march('extractfile', x, "SimpleTest.mla", cat(TEMPDIR,"PrimesBack.jpg"));
            found := true;
        catch:
        end try;
        if found = true then break; end if;
    end do;
    if found<>true then
        error "a problem occurred while attempting to extract the temp files."
    end if;
    IMAGELOC := cat(TEMPDIR,"PrimesBack.jpg");
    use Maplets[Elements] in
    maplet := Maplet(
     [
       Label(Image(IMAGELOC)),
       "Did this maplet show an image stolen from the MaplePrimes website?",
       [
         HorizontalGlue(),
         Button("Yes", Shutdown("Image was shown")),
         Button("No ", Shutdown("Image was not shown")),
         HorizontalGlue()
       ]
     ] ):
    Maplets[Display](maplet);
    end use;
    try
        FileTools:-Remove(IMAGELOC);
    catch:
        error "a problem occurred while attempting to delete the temp files."
    end try;
end proc:
                                                                                                                                           
LibraryTools:-ActivationModule("SimpleTest.mla",initproc);

acer

Doug, you are quite right. The help for InstallerBuilder could do with a lot more detail. It may not even be your ideal long-term answer. Multi-part mime handling sounded exciting. But the InstallerBuilder is a very nifty little tool for distributing about one's Maple packages. There's all kinds of power behind it. I find that this is true of Maple all round -- so many darker corners hiding a true wealth of functionality. acer

Given that the unit-simplification (as described in Robert's very nice reply) occured even without loading Units[Standard], one might also try issuing only, Units[UseSystem](FPS): and then get the unit-simplification, as done in the posted example, to the FPS system. Of course, reading the help-page ?Units[Standard] might show whether that package's wider functionality is also wanted. There are also context-menu operations for converting expressions with attached units from one system to another. acer

Given that the unit-simplification (as described in Robert's very nice reply) occured even without loading Units[Standard], one might also try issuing only, Units[UseSystem](FPS): and then get the unit-simplification, as done in the posted example, to the FPS system. Of course, reading the help-page ?Units[Standard] might show whether that package's wider functionality is also wanted. There are also context-menu operations for converting expressions with attached units from one system to another. acer

Right. I'd just assumed that you would hard-code the relative path to the image file in the Maplet. And I'd likewise assumed that that path would be relative to the toolbox/Simple/ location. As far as where the installer puts things, I believe that it may use cat(kernelopts(homedir),"/maple/toolbox/") concatenated further with the title "name" for the toolbox as given when constructing the installer (as seen in the Interactive routine, for example). There is also some option for a "network" installation. This might use kernelopts(mapledir), but I didn't check. nb. You mentioned uninstaller, but really it is the SimpleMaplet.mla which is technically the *installer*. The uninstaller is a separate .mla which when run should autoexecute and remove the toolbox/Simple files. As for getting rid of all those panels, well, maybe the techniques used by InstallerBuilder can be inspected and mimicked. For that, I'd suggest studying the workings of the routines InstallerBuilder:-Build and LibraryTools:-ActivationModule . You might be able to study the help-page for LibraryTools:-ActivationModule and construct a more lean and direct was to get an auto-opening/executing .mla archive to do just your particular tasks. InstallerBuilder is just one very specialied instance of using that, I think. acer

Maple didn't have ToInert/FromInert for many years. Now, inspection shows that it is used in many places, internal to various packages. So you have (re)discovered a very useful piece of Maple. There's nothing wrong with that. It shows that you are using Maple more fully than do most. My original question was honestly put. I wondered whether you had done it for some special reason. I also half-expected someone else to point out some difference, good or bad. This forum is made better by discourse. Jacques pointed out that the simplicity of your form means that it's easier to understand than what ToInert gives. I also mentioned ToInert/FromInert so that other readers might get a fuller picture, and because it's natural to mention it. I saw no disparagment of your idea. acer

(Pardon my use of Linux filesystem paths.) It took a while, but I figured out that the InstallerBuilder "scripts" are just supposed to be single procedures. So, I suppose that you might be able to put the whole Maplet into a single proc, as the Finish panel script. I didn't try that. I chose to do it another way, by embedding the Maplet in an autoexecuting help-page, which gets called by the Finish panel script. For the Finish panel in Installerbuilder, I added this as the script: proc() try help(StartMe); catch: end try; end proc; Next, I edited your Simple.mw worksheet a little. I removed the restart. I joined the rest into a single execution group. I select the whole group and toggled it as autoexecute. Then I reselected it and collasped that selected Document Block. Then I saved it. To test, just reopen it in a new session, and check that it autoexecutes. Next, I saved that worksheet to a .hdb help-database as an "active" help-page. The .hdb needn't be present, it will get created by the INTERFACE_HELP() call. I did that like so, libname:="/home/acer/dmeade","/usr/local/maple/maple11/lib"; startmefile:="/home/acer/dmeade/files/Simple.mw"; tmp := readbytes(startmefile, TEXT, infinity): fclose(startmefile); INTERFACE_HELP(insert, active = true, topic = "Simple,StartMe", aliases = ["startme","StartMe"], text = TEXT(tmp), library = "/home/acer/dmeade/Simple.hdb"); Then I ran the InstallerBuilder:-Interactive() command. I added only these files: Simple.hdb as lib/Simple.hdb PrimesBack.jpg as misc/PrimesBack.jpg It was quite nice to see, that the InstallerBuilder knew to suggest lib as the default location for the .hdb file. And, of course, when I open the resulting Simple.mla file in Maple it starts the installer and unpacks the materials. On Linux, it unpacks it under /home/acer/maple/toolbox/Simple/ . And it is sweet, that /home/acer/maple/toolbox/Simple/lib/ is automatically recognized by Maple and added to libname. In fact, by the time the installer gets to its last (Finish) panel, and triggers the script I described above, the .hdb can already be used. And so the help(StartMe) query actually loads the Simple.mw page, inline in a worksheet, and autoexecutes the collasped Document block, and the Maplet runs. The only action I had to do was to have Maple start/open the Simple.mla file. acer

How hard would it be for an expert maple user (or small group of same), cognizant of LaTeX and TeX, to improve Maple's `latex` command? What is there? `latex`, `latex/latex/Typeset`, LaTeX:-ExportInert ? Is there much more? I'm just talking about the latex() command, for expressions. Fixing LaTeX export of full worksheets looks to be less feasible -- because it uses some different hidden mechanism, has much more that's broken, is weird in its use of the style file, and might need far more effort. acer

For those who are interested, ToInert and FromInert allow pretty much the same sort of programmatic inspection and manipulation of expression trees. Except that ToInert and FromInert, which are provided as part of Maple itself, can do more. They can also handle procedures, more datastructures such as tables, rare (at the top-level) objects of type SDMPolynom, etc. acer

What sort of functionality would this give over and above what ToInert & FromInert give? acer

You might start out by ready the help-page that comes up in Maple when you enter this, ?external_calling After that, you might follow the pages referenced at its end, in its "See Also" section. acer

I never found the help for InstallerBuilder to be very useful. It's not very full, especially concerning what appears to be ability for scripting. What I have had success with is the InstallerBuilder:-Interactive() routine. However, what I've used it for in the past is simply to "Add" files (there's a button for that). I add files, specifying where it is to grab them from, and where it is to install them when run. It outputs a single .mla file, which contains all the bundled files. When this .mla is opened in the GUI, a maplet gets run, with a few panels, just like an installer. The bundled files may contain other .mla files, .hdb files, example worksheets, dynamic/shared libraries, etc. Once or twice, I've had it create and bundle its own uninstaller, too. I suspect that it was designed, originally, for 3rd party MapleConnect products, so that authors could create their own installers. I don't know if it's still used. One thing that I find interesting, is that Maple seems to find directories like /toolbox/XXXX/lib and /toolbox/XXXX/bin. and append libname and PATH with them automatically. Does this not make such locations ideal for placing user-authored packages, especially when bundled/redistributed for others? I also find interesting the idea that a .mla archive may be autoexecuting in some way. Something clearly gets created, which does the work. So, if the InstallerBuilder is not to taste, I wonder whether one could find and utilize the tech behind it regardless. acer

The .mla maple archive format itself supports some of what you mention. It can contain more than just .m files. It can contain image files, other .mla archives. Maybe any other file, I think. A .mla archive can also be set to execute and unpack files, with a popup progress maplet, when opened in the GUI. See ?InstallerBuilder . Or run InstallerBuilder:-Interactive() . acer

Sure, the bad behaviour might be on the part of the webmail system. But a compressed worksheet format might sidestep it nicely. Thanks for your details, acer