Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 23 Mar 2018, 14:38
All times are UTC - 4
 Forum index » House Training » HOWTO ( Solutions )
How to Have Menu Entries for External & Wine Apps
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [5 Posts]  
Author Message

Joined: 16 Jun 2008
Posts: 2278
Location: 500 seconds from Sol

PostPosted: Fri 25 Mar 2011, 12:56    Post subject:  How to Have Menu Entries for External & Wine Apps
Subject description: Very, VERY! Easy BASH Programming for Dummies: Don't Panic

This "How To" is long because (a) it assumes you know nothing beyond simple stuff under Windows, and (b) I tend to be long-winded. The actual, necessary, instructions take up less than 1/4 of the text.
External Applications, sometimes called portable applications, are physically located outside your SaveFile. Playdaz discussed the technique for using them in a post called “Program Folders.” More recently, DaveS built upon that idea to create the FoxyFun Pet, and the Opera11_mnt_home Pet which will, respectively, run Firefox and Opera11 from your home partition. Both those pets create menu entries, and essentially all this post does is summarize how he did it as that technique can be employed generally to any application “installed” outside the SaveFile. It can also be used to create Menu entries for programs running under Wine. For illustration purposes, I’ll discuss my creation of the Iron_mnt_home Pet, but also give the code for any program you install under wine.
Edit 2/19/13: The discussion following is still valid for applications in general. However, the current version of SWIron --and probably Chrome & Chromium-- can no longer be run as root. Starting its executable in a terminal explains that some modification can be made, but it is beyond my current ability to interpret how to do it. Opera and firefox, downloaded from their publishers continue to work as Program Folders.
Edit 2/25/13: To get them to work, see torgo's post, the third post below this.
The first thing I did was create a temporary folder: just click the desktop icon representing the partition in which your Puppy was installed, sometimes referred to as the “home” partition. Now Right-Click an empty space and select “New>directory." Give it any name. Then I downloaded the Iron tar.gz file from SWIron into that directory. Then I clicked the tar.gz file, which opened my compression/decompression app --tar.gz being a compressed file-- clicked “Select All" and clicked “Extract." All the Iron files were extracted neatly into a folder named “iron-linux." So it turns out that I didn’t have to decompress Iron in a temporary folder as it created its own folder. On the other hand, had it not done so, I’d might have had files scattered alphabetically all over my “home" partition, which would have made it difficult to delete or upgrade Iron.
As the temporary folder was no longer necessary, I again clicked the desktop drive icon reflecting my home partition, dragged the iron-linux folder to that partition, selected “Move" and then deleted my temporary folder.
Next I clicked the iron-linux folder to open it and observed a file conveniently named “iron." It looked like an old fashioned ship's steering wheel, suggesting it might be the executable. I clicked it, and the Iron web-browser opened. I should note that my home partition is formated as a Linux partition. I’m not sure I’d have been so successful had it been formated as Fat, VFat or NTFS. The instructions given below for creating a script would have still have worked. However, if your Home partition is formated Fat, VFat or NTFS, before proceeding further you'll want to make certain that the application will EVER run in your version of Puppy. I'll explain later, but for now just click the "file" or "home" icon on your desktop, then click the "my-applications" folder. Drag & Drop & select "copy" the entire folder containing your external application into the "my-applications" folder. [Tip: copying an 150 mg Libre-Office folder into "my-applications" folder when you only have 50 mg left in your SaveFile may prove problematic. Don't do it. If you still want to use the external app, first resize your SaveFile]. At any rate, now that your "external application" is entirely within my-applications, click on its executable. If it doesn't start, some file or files are missing from your operating system and its best to postpone further efforts and delete both the "external application" folders within my-applications and outside your SaveFile. Become an accomplished Guru or wait for someone else to figure out what was missing and try again. Frankly, I've chosen the second option. If the application started, it's safe to proceed and you can delete the "external application" folder from my-applications.
If all I wanted to do was achieve easy access to the program, I could have just dragged the iron executable to my desktop, and perhaps given it an icon to make it look pretty. But I wanted a menu entry so that I could access it when my desktop was cluttered.

Edit August 9, 2017. See Below
To open any application its executable file must be called. There are many folders --referred to as “on the path"-- which your file manager is setup to look into for such executable files, but neither outside your SaveFile nor the “drive_C” folder created by Wine are among them. Fortunately, Barry K incorporated one folder, otherwise not used and easily found, which is “on the path.” Click on the “file” or “home” icon on your desktop, and a window will open to your “home” folder. In Puppy, your home folder is sort-of-like "Documents and Settings" is under Windows. Your home partition is sort of like "C:\" would be in Windows, assuming you instaled Windows to C: drive. Within your home folder, you’ll see another named “my-applications.” And within that folder, you’ll see another named “bin.” My-applications, and all the folders within it, are "on the path."
You can’t just move an executable from the location where an application installed it and expects to find it, into that my-applications\bin (hereinafter just called “bin”) as that will break the integrity of the application. But you can create two types of files which, if placed in bin, will “call” the executable from there.
The first is a symbolic link (or symlink) which is like a Windows shortcut, but more powerful. When you drag an executable to your desktop, it automatically creates a symlink. But when you drag it to a folder it gives you several options including “copy,” “move,” and “Link (Relative).” Chose the latter to create a symlink. Useful as they are, regretfully symlinks don’t survive attempts to include them in Pets so you’d have to manually recreate them in every new or additional Puppy. [Edited 4/5/11: See my post on how to include symlinks in Pets made using Petmaker: http://murga-linux.com/puppy/viewtopic.php?p=510654#510654.] As I wanted to just do it once and be done with it I used the second method for calling an executable.
The second is a script file. Puppy comes with a built in programming language, BASH which is very powerful and can be very complex if its full power is needed. Fortunately, we only need one command,exec" which takes one “argument,” the location of the file to be executed.
Right-click on an empty space in the bin folder and choose “New>script” and give it a name. In this case I called it “iron.” Then I Right-Clicked my new iron script and selected “Open as Text.” The file which opened already had the code which told Puppy that this was an EXECUTABLE file which required BASH to be started. That code read:
Going to the end of the line I pressed RETURN to start a new line, and typed the command “exec” --without the quotes-- followed by a space. Now I took a look at the window I had opened to the iron-linux folder. At its top, it gave me the full path to that folder: /mnt/home/iron-linux. So I typed the entire path, followed by a / and the name of iron’s executable, iron, added a space and the command "$@" including the quotes. Frankly, I’d don’t know what that means, but it was necessary. Perhaps its comic-bookeese, telling BASH “Now that you’ve done your job, f_k off!”
Now my script file read:

exec /mnt/home/iron-linux/iron "$@"

Clicked SAVE, and my script was done.
You can rename a script and change the second line to identify a different executable, and you have a new script calling a different executable.
In the following instance,
wine /root/.wine/drive_c/'Program Files'/SomeFolder/MyProgram.EXE

BASH is told to start the Wine Application, and wine is told to open MyProgram.EXE which is located in
/root/.wine/drive_c/'Program Files’/SomeFolder.
Note the space between wine and /root...
If you’re in your “home” folder with hidden files shown [Click the "eye" at the top of the window so that the word "All" appears], and you scroll down you’ll see a folder named .wine --starting with a “.”. Opening it will reveal a folder named “drive_c” without the quotes. And opening it will reveal “Program Files” without the quotes. Because there’s a space between the word “Program” and the word “Files”, you have to put both words between the ‘ quotation marks so that BASH takes into consideration the space. Otherwise it stops reading at the end of the word “Program” and reports an error, not having found something with that name. I don’t know why it isn’t necessary to tell BASH "$@" when Wine is called.

Leaving bin opened, I searched for a usable icon. Although there are many folders where you can put an icon, putting it in bin simplifies the creation of the desktop file you’ll need for your application to appear on your menu. As it happens, SWIron was kind enough to provide an appropriate icon in the same folder as its executable. [Right-Click a window's "eye" to show icons as thumbnails]. So I dragged and dropped it into bin, and chose “copy.”
Now it was time to open the application folder in which desktop files are housed.
At the top-left of the window opened to bin is an UpArrow. I clicked on it a couple of times until I reached a folder simply named /. This is actually known as “root” being the “top” of the upside-down Linux Tree structure. [Because of a long history of Linux usage, which I’m powerless to change, there’s a folder within / --called “root”-- which has the name “root” but which is, actually, your Home folder --identified as “~”. The later is not to be confused with a folder named “home” which has nothing to do with your user files, nor with your “Home Partition,” /mnt/home, which is where Puppy’s boot and SaveFile are found].
At any rate, in / --the real root-- is a folder named “usr”. Click on that, and then click on the folder named “share,” and then click on the folder named “applications.” While it is possible to write a desktop file from scratch, it’s easier to modify a desktop file which has already been written correctly. Since Iron is a web-browser, and Dillo is a web-browser whose desktop file was written, I believe, by Barry K, I assumed that he knew what he was doing. So I Right-Clicked the file named “Dillo.desktop” and selected “Open as Text.” Now, before I had a chance to screw up Dillo, I quickly clicked File>Save As and gave it the name “Iron.desktop.” Scrolled up a bit to make sure there still was a Dillo.desktop file, I then scrolled down, Right-Clicked Iron.desktop and selected “Open as Text.”

Leaving the structure untouched, I then overwrote what had been Dillo’s arguments so that the file now read:

[Desktop Entry]
GenericName=Iron web browser
Name=Iron web browser
Comment=Iron web browser from mnt/home

The text bolded above was not bolded in the desktop file. I’ve bolded it here to show the four essential arguments you want to have written correctly. The Name argument is the name which will appear in the Menu. The Categories argument identifies where in the Menu it will appear. The Exec argument identifies where the executable will be found --in this case the script I just wrote. And the Icon argument identifies where the icon which the Menu will display is to be found. The changes having been written. I clicked File>Save.
Now it was time to test. I clicked the iron.desktop file. I don’t recall if Iron opened. Sometimes you have to restart the windows manager (shutdown>restart X), and sometimes you even have to reboot before your new desktop file will both work and show up in the menu. But before you do anything else, make sure you didn’t overlook the listing of the application in the menu. From top to bottom, applications are listed alphabetically, but all applications whose name starts with a capital letter are listed before any application whose name starts with a small letter.
If, after a reboot, your application or its icon doesn’t appear in the menu, or doesn’t open when you click the menu entry, its time to retrace your steps and see what was broken. Open a window to /my-applications/bin and click on the script file. If that doesn’t open the application, open the script as text and make sure you properly identified the executable and its path. Linux is Case Sensative. Iron (with a capital "I") and iron (with a small "i") are two different files. And irOn is a third file. If the script called your application, then make certain the desktop file properly identified your script as the executable. And the icon you placed in bin as the one to be used.
Now that you’ve done all this work, you’ll never want to do it again. You avoid this by calling up Trio’s Petmaker. You’ll find it at http://www.murga-linux.com/puppy/viewtopic.php?p=290171. In about five minutes you’ll have created a pet which will properly install the script, icon and desktop file in any new or additional Puppy, and which can be used with any future version of the application you download.
If tomorrow I were to download a new version of Iron this is what I would do. First, I’d change the name of the present iron-linux folder to something like iiron-linux. Next, I’d again unpack the iron.tar.gz in a temporary file, and see if the name of the folder it creates is still iron-linux. If not, I’d change the name of that folder to iron-linux: Right-Click, Rename. Next, I’d open that folder to see if its executable was still called iron. If not, I’d change its name to iron. Operating systems speak their own language. Consequently, it usually doesn’t matter to an operating system what we, for our benefit, have named a file or folder unless it was part of the original operating system. Then I’d Move the iron-linux folder to /mnt/home, open it and click the iron file to see if it works. If it did, I’d close Iron, and then click on the menu entry for iron. If it opened, I can then simply delete the folder I named “iiron-linux.” If, at some point, something didn’t work and I still wanted to use the new version, I’d have to repeat the steps I took the first time, beginning with decompressing the tar.gz.
One last note. Like every other application in Linux, fans of BASH are constantly “improving” it, and from time to time Barry K, or a Puppy dev uses a different BASH version. The upshot is the occasionally the script or desktop file you wrote in one Puppy will not be recognized as a script or desktop file in a Puppy using a different BASH version. Make a mental note of the icon identifying script files. Desktop files always appear using the icon you selected. If in another Puppy the script you wrote in one Puppy doesn’t appear with a script icon, or the desktop file doesn’t appear with the icon you assigned, it may be because the new Puppy is using a different BASH version. All is not lost. Merely change the name of the old script/desktop file, create a script/desktop file with the old name, open both files in a text editor and copy the text from the old file to the new one. Save. Delete the old file and create a new pet, giving it a unique name, such as with a different version number.

Happy computing,


Edit 8/09/17: Following my post here on how to create menus for wine's built in programs, http://www.murga-linux.com/puppy/viewtopic.php?p=882255#882255 in responding to a question on the Beginner's SubForum, it occurred to me that three files weren't necessary -- that the executable could be called directly from the Application's Desktop file @ /usr/share/applications. At most, in addition to the desktop file you might want to use an icon not already on your system. Either way, a desktop file for an application running under wine would look something like this:

[Desktop Entry]
Exec=wine /root/.wine/drive_c/'Program Files'/FOLDER_IF_ANY/MY_APPLICATION.EXE
Categories=YOUR_CHOICE; ## copy from an application already appearing there

If your application is a portable, the argument for Exec= would be something like'


Change wine to wine.sh if using wine-portable.

One advantage of providing specifics of the executable in the Exec argument rather than a separate bash script is that Radky will shortly release a new version of PupMenu. It will parse the Exec argument in desktop files and, if the first 4 character's are wine, generate listing for that application under the Wine category of such menu, as well as the specific category which you've assigned.

Last edited by mikeslr on Wed 09 Aug 2017, 21:03; edited 6 times in total
Back to top
View user's profile Send private message 

Joined: 16 Jun 2008
Posts: 2278
Location: 500 seconds from Sol

PostPosted: Wed 20 Feb 2013, 20:14    Post subject: Getting LibreOffice and other Apps as Program Folders  

Hi All,

I recently ran a series of tests that revealed running Libreoffice as a Program Folder made fewer demands on my system than running it as pet installed to my SaveFile, or even as a loaded SFS. That suggest that Program Folders may be the best way to run an application on a computer with limited RAM or a slow CPU. But see http://murga-linux.com/puppy/viewtopic.php?p=686093#686093 for yourself, for other reasons to employ Program Folders and, perhaps, why not to.
One of the conclusions I discussed in that post was that using Program Folders (aka Program Directories aka External Programs) makes the most sense if they are of applications you frequently have open, such as Browsers, or are of a suite of applications not all of which you need to have opened at the same time.
Without regard to any question of the general utility of using a Program Folder rather than a pet or SFS –one size doesn't always fit all-- for the sake of completeness I figured you might want to know how to create your own. The previous post on this thread gave as an example downloading the tgz direct from its publisher. http://www.murga-linux.com/puppy/viewtopic.php?t=66237. And Lobster has reminded us of the availability of Portable Linux Apps, http://portablelinuxapps.org/ which are essentially prepackaged Program Folders, that are supposed to be functional in “Ubuntu, Fedora, debian and derivatives.” As such they should work in Lupu, Lucid, precise-pup variants, and Exprimo. Some do, some don't. Puppies don't always have the files built into an Ubuntu or debian –part of the bloat we excise-- that portable apps expect to be present. But only thing lost in trying them is bandwidth and time. Just download one you might be interested in, set it to executable (using Rox, Right-click>select properties>check each of the 3 executable boxes) then click the icon. If nothing happens –not a good sign-- drag it to /my-applications/bin and select Link(relative). Reboot and try clicking the link. If still nothing, open a terminal at the original executable and type its name. You might receive a message telling you why it's not working. But don't ask me for help. I'm just a tinkerer. If you're into Games, you might also try those at http://www.portablelinuxgames.org/. If you find any you like you can add them to your menu per the instructions of the previous post, except that you call the application by name rather than the executable within the application. For example, Code:
exec /mnt/home/FBReader "$@"

You can also obtain Program Folders by unpacking pets and SFSes. To unpack a pet, change its ending from .pet to .tgz and then click it. Your default archiver will open asking whether you want to install a slackware package or decompress the file. Choose the latter. Your archiver will create a folder. You can change its name for convenience and move it to where you want it to be. To unpack an SFS, you mount it (right-click) and select “view.” In the window which opens, select “show hidden files” just to be certain that you don't miss any, then press Ctrl-A and drag everything to a folder you previously created. Select copy. Somewhere within the folder of the decompressed pet or mounted/copied SFS will be both the executable and an appropriate icon you can use in your script and desktop files per the instructions of the previous post. The executable will usually, but not always, be in a /bin or /sbin folder, but there may be several, and its name, while suggestive, may not exactly be that which would appear on a menu. See, for example, the discussion of Libreoffice below.
Get yourself a copy of FreeOffice, currently available at http://www.freeoffice.com/en/download –or keep looking for it if it temporarily becomes unavailable. FreeOffice is a version of SoftmakerOffice, cut down in the sense that FreeOffice only includes a WordProcessor, and applications for creating/editing spreadsheets and presentations. All are able to read and write Microsoft Office files. To obtain it you have to provide an email address for them to send you a serial number. They don't abuse it. A couple times a year they'll send you a link to download free fonts. But they'll also advise you of the availability, for free albeit time-limited, of their beta upgrades to SoftmakerOffice, and when they do upgrade SoftmakerOffice, they'll offer it to you at a discount. Sometimes, when they do publish a SoftmakerOffice upgrade, they also offer to those on their mailing list a free copy of the now discontinued version. When you run either the FreeOffice or SoftmakerOffice installation app it provides you with a choice of creating either a full install --that is to your operating system-- or a portable install. The latter is a Program Folder you can copy to other computers or a USB-Key. I did a quick comparison of RAM and CPU usage by FreeOffice and LibreOffice. FreeOffice appears to use slightly less RAM but more CPU.
Oddly, regardless of what species of Linux you use, if you download either LibreOffice or OpenOffice directly from their publishers you obtain a bunch of rpm files. Rpm is the native package format of Fedora, Mandriva, and PCLinuxOs packages; while the native package format of debian and Ubuntu is deb. Puppy has pets for decompressing rpms, so its probably possible to manually decompress the rpms, and combine them in one directory to create a Program Folder. But is far easier to use 01micko's GUI to obtain LibreOffice, http://www.murga-linux.com/puppy/viewtopic.php?t=65918, albeit after you've run that pet you'll have a SFS in xz format you'll have to decompress. (Lupu/Lucid can not natively handle xz compression). If you have knowledge of the programming language --I think BASH--with which 01micko wrote the script in his pet, you can probably edit it to terminate prior to its repackaging everything as an SFS. But then, you probably wouldn't be reading this post.
If you install Libreoffice4, or load a Libreoffice4 SFS, browsing your files you'll discover that the actual executables are located in /opt/libreoffice4.0/program. Desktop are used to generate menu entries. They contain arguments as to the executable to be called, the icon to be displayed and the menu category they are to appear under. Normally they are found in /usr/applications. Libreoffice, however, creates desktop files in /opt/libreoffice4.0/share/xdg pointing to the executables found at /opt/libreoffice4.0/program and the icons found at /usr/share/icons/hi-color/48x48/apps. It creates a symlink to that desktop file in /usr/share/applications. Previous versions operated in the same way, differing only with respect to the version identification shown in the name of the folder or icon, i.e. the 4.0 following libreoffice. Despite this name change, the same icons were used. Similarly, the same name was used for the executables: for example the wordprocessing application is actually swriter.
In creating a pet to access the applications in Program Folder Libreoffice4.0-External, as I intended to employ primarily the same technique discussed in my prior post, to save myself a lot of typing, and to make it easy to later upgrade to version 4.2, or 5 or whatever, I decided to drop the version designation in icon names. Within a temporary folder on a Linux formatted partition I created a folder named LibreOffice-External-4.0. Within that folder I created two other folders, one named root, the other named usr. Within root I created a folder named /my-applications, and within that a folder named /bin. Within bin, I created the first of eight scripts which I named sbase: using rox, right-click>New>Script. I opened sbase in my text editor and typed in the second line to the following code:

exec /mnt/home/LibreOffice-4-External/opt/libreoffice4.0/program/sbase "$@"

Saved. Right-clicked>properties, checked all boxes under Executable, closed, clicked to see if it would open the database manager. Closed. Opened the sbase script in my test editor and saved it as scalc. Opened scalc in my text editor and changed the second line to read, code:

exec /mnt/home/LibreOffice-4-External/opt/libreoffice4.0/program/scalc "$@".

Save, tested and proceeded to do the same with all LibreOffice's executables (see attached photo). There's a desktop file called xsltfilter.desktop. Both it, and startcenter.desktop open a wizard from which you can then open the application of your choice. I couldn't find any distinction between them, so I only created a script for the latter, which I called soffice.

Next, within, at the top level of my LibreOffice-External-4.0 folder I created a folder named usr; within that one named share, and within that two folders: one named applications and the other pixmaps. Into pixmaps I copied the icons from
/mnt/LibreOffice-4-External/usr/share/icons/hi-color/48x48 changing the names, as previously mentioned, by dropping the version designation.

Into the above mentioned applications folder, I copied the desktop files from /opt/libreoffice4.0/share/xdg, changed their names to be more generic, opened each and edited their executable and icon arguments to respectively reflect /root/my-applications/bin and /usr/share/pixmaps. For example, my writer file now reads, in pertinent part:

[Desktop Entry]
Name=LibreOffice Writer
GenericName=Word Processor

You may have to experiment with the Categories argument to get an application to appear on your menu. Open the desktop files of other applications which do appear on the menu and place the key words they use at the beginning of your desktop file's category argument. Delete words you doubt are useful, such as the above Red-Hat-Base.

When Libreoffice publishes a new version, unless it makes significant structural changes, it will be a simple matter to revise my pet by merely changing the folder referenced in the script files in /my-applications/bin.

When you're finished creating/placing/editing files in your Libreoffice-External-4.0 folder, open a terminal at the folder in which it is located and type, code:

dir2pet Liboffice-External-4.0

Then follow the instructions. Puppy will create a pet named Libreoffice-External-4.0.pet.

One last thing I should mention. While examining files in the Pup I was using to write this, although I am now using Libreffice-External, and do now not have Libreoffice 3.x installed or loaded as an SFS, apparently at some point I had. Uninstalling that pet or unloading that SFS apparently did not remove the Libreoffice3.x folder or its contents from /opt. Figure about a 100 Mbs of waste of my SaveFile.

Hope this helps,

Description  Snapshot of folders for comparison

Filename  LibreOfficeConfiguration.png 
Filesize  94.07 KB 
Downloaded  343 Time(s) 
Back to top
View user's profile Send private message 

Joined: 23 May 2010
Posts: 2545
Location: near here

PostPosted: Thu 21 Feb 2013, 06:50    Post subject:  

Nice work, added link to thread on the wiki

helping Wiki for help
Back to top
View user's profile Send private message Visit poster's website 

Joined: 09 Sep 2011
Posts: 67

PostPosted: Fri 22 Feb 2013, 00:37    Post subject:  

Edit 2/19/13: The discussion following is still valid for applications in general. However, the current version of SWIron --and probably Chrome & Chromium-- can no longer be run as root. Starting its executable in a terminal explains that some modification can be made, but it is beyond my current ability to interpret how to do it. Opera and firefox, downloaded from their publishers continue to work as Program Folders.

Ironically, the new Chrome and Iron happen to be the exact reasons I'm reading your tutorial. I just got them working in Lucid 5.28 as root, and now I want to add them to the menu and the default browser selection list.

I downloaded both in 32-bit .deb format from the original sites (Iron downloaded from SRWare, Chrome downloaded from Google), saved them to my drive and clicked to install them with petget. After "installing" them with petget, here's how I got them working as root:

For Iron:
go to /usr/share/applications and open iron.desktop as text
add " --user-data-dir" (with a space but without the quotes) to the end of the "Exec" line and save the file. Clicking the iron.desktop file should now launch Iron.

For Chrome:
go to /opt/google/chrome and open google-chrome.desktop as text
add " --user-data-dir " to the Exec line located around line 108. Put it just before the %U. (Again, without the quotes but with a space before and after.) Clicking on google-chrome.desktop should now successfully launch Chrome.
Back to top
View user's profile Send private message 

Joined: 16 Jun 2008
Posts: 2278
Location: 500 seconds from Sol

PostPosted: Sat 09 Mar 2013, 00:02    Post subject: New script argument for SWIron  

Hi All,

Thanks to Torgo's explanation, just above this post, I am once again able to run SWIron from /mnt/home.
SWIron makes it rather difficult to locate its Linux version. I had to specify "SWIron Linux deb download" otherwise only the Windows version showed up. Finally found it at:
Saved it to a temporary file and extracted it to a folder. Examination of the folder revealed that its executable, iron, was now located in THE WITHIN /usr/share/iron folder, and that a desktop file was similarly located in the within /usr/share/applications folder.
Since I wanted to run Iron from /mnt/home, I changed the name of the extracted deb folder to SWIron and moved it to /mnt/home. Then in /root/my-applications/bin I copied the iron.png and created a script named SWIron with --thanks to Torgo-- the following argument, Code:

exec /mnt/home/SWIron/usr/share/iron/iron --user-data-dir"$@"

Next I copied the supplied desktop file to the systems /usr/share/applications, and opened it to make the following changes:


The supplied desktop has Iron showing up in the network submenu.

Restarted X.


Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [5 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » HOWTO ( Solutions )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1773s ][ Queries: 12 (0.0136s) ][ GZIP on ]