For part of a large university project I have built a large java based application. To make "installation" cleaner I am aiming to write a script to copy the jar to a hidden file in the users home directory then add a menu &/Or desktop launcher.
Since I do not know what platform the markers shall be using it seems sensible to make this generic so I was going to build a shell script and a batch file.
The shell script starts off simple, check the directory doesnt already exist, make it and copy the file accross.
Then it comes to making a launcher of some kind. I presume each desktop environment shall do things differently.
After 10 minutes with google it seems everything suggested is autotools but since I have no knowledge of this it seems a bit overkill.
Is there an easy way to achieve what i need?
Thanks
These days, basically all of the desktop environments uses desktop files. For the specification for those files, see the Desktop Entry Specification.
Normally, they're put in /usr/share/applications on the system. Those files are then read and used to construct the menu.
If you have the ability to write to the system /usr/share/applications directory, that's obviously simplest, but if you had that, you would probably be putting the JAR file somewhere other than a hidden directory in the user's home directory.
If not, the path that's supposed to be honored is ~/.local/share/applications. If you drop a desktop file in there, it should show up for the user. (This is somewhat newer; I don't think GNOME 2 supports, it for example. Older desktop environments had various special places for these files.)
Then, the problem basically reduces to figuring out what to write for the Exec line in the desktop file. (See the desktop files on your system in /usr/share/applications for some examples.) If you're lucky, you can get away with just sticking a java command in there, but the details will depend on your application.
Related
I am writing a C# application (in Visual Studio on Windows) that will be run as a mono application on Unix (Raspbian aka Debian). I am a Unix noob, and though I have read (well, skimmed) the Linux Foundation Filesystem Hierarchy Standard I am still not completely clear on where I should put the files my application will need. I have:
The compiled C# application (app.exe). I thought I would put this in /usr/bin, except that the application is not run directly (it is invoked by "mono app.exe"), so maybe /usr/libexec is a better location?
Configuration files (there may be more than one) (app.1.conf, app.2.conf, etc.). If they are not user specific, I would think /etc/app (a directory, not a file) would be a good place for these. How about if they are user specific? /home/?
Log file (app.log). Seems that /var/log is the right place for this.
Thanks in advance for your input.
You should look at an already established Mono app for reference. For example let's take MonoDevelop:
The exe file goes to /usr/lib/{appnameinlowercase}/bin/ , but they place a launcher script in /usr/bin, named {appnameinlowercase}, for easy launch from the command line (this script just calls exec mono YourAppName.exe).
In .NET the config files need to be in the same directory as the executable file, so you could place them in /usr/lib/{appnameinlowercase}/bin, then later for convenience, put symlinks to them from /etc/{appnameinlowercase}/.
Correct, /var/log/{appnameinlowercase}/ should be fine.
I've been developing in Idea on Linux for a little while now and am getting used to it after the initial pain of transitioning from Eclipse.
One of my problems has been how to configure the file manager. I'm running Openbox on Arch Linux and I can't see an obvious way (despite some extensive Googling) to specify a default file manager and I'm not sure if Idea would use it if I did.
Does anyone know how to specify the file manager in Idea for Openbox on Linux?
Click IDE Settings -> External Tools, and then click the Add button.
Specify the tool - like in this screenshot:
http://kobo.github.io/grails-improx/img/idea-external-tools-edit-sh.png
Basically you can specify any external program you want.
The program path should point to the binary file you want to use as a file manager (for example thunar is a great one: /usr/bin/thunar (you can find the correct path by executing "$which thunar" in a terminal)).
The parameter & working dir should be "$FilePath$" & "$FileDir$ (or you can choose other variables if you prefer different functionality)
I have a standalone server running Cygwin -- I did not setup this server, it was inherited. Anyway, I'd like to know what options the installing admin selected in the setup program.
I've read that I could look in /etc/setup, /etc/postinstall, or /etc/preremove but there are a lot of packages in those directories... same goes for the output of cygcheck -c.
I don't want to know every single library on the system... just how to duplicate the install. Is there a way to determine which packages were select in the GUI setup program?
Thanks!
Cygwin is pretty standalone. You should be able to archive up the entire Cygwin directory (and subdirectories) and move it to the same location on another system.
If you archive it up I recommend 7-zip. You can get it free here. The built in Windows archiver can create permission problems when an archive is extracted on a destination system. I recommend 7-zip for both archiving and unarchiving. If you use the built in Windows archiver and then move it to the new system and extract it - it will extract without errors. However you may find things don't actually work right while using some Cygwin applications
If you don't copy everything you won't move any of the original admin's custom changes.
I have what might be a simple question and might be....a more complex one. We are preparing to add NSIS to our software, that is, we want people who use our software to be able to create installers using NSIS, but through our software. (We'll be creating functions using NSIS, acknowledging NSIS, etc.) What I am trying to figure out before we get started is how many/what files our customers will be required to have on their hard drive for NSIS to work. So, we just need to know if nsis can be used standalone or if it requires the user to install it into program files, or if it requires a lot of different files in AppData - If we have to bundle a few .dlls, that's not a problem and is expected. Ultimately, if we end up having to bundle NSIS as well, that's fine - We just want to make sure it'll work on other people's computers without telling them to go download it.
MakeNSIS does not read/write from/to the registry or anywhere else and only needs a handful of files for minimal operation.
To build a simple installer you need:
NSIS\MakeNSIS.exe (Just calls Bin\MakeNSIS.exe)
NSIS\Bin\MakeNSIS.exe
NSIS\Stubs\* (If you are only going to use a specific compression mode you only need one, and the uninstaller file if you want uninstall capability)
If you want to use the Modern UI you need its header files, some files from Contrib (Graphics and UI) and system.dll and nsDialogs.dll from the plugin folder.
Everything else is optional but I would recommend that you also bundle:
NSIS\Include
NSIS\Plugins (You can remove stuff you will never need; dialer, splash etc)
NSIS\Contrib (Language files, graphics and UI)
You can find license information here.
You could also just ask the user to install it and enter the path to it in your setup program...
I would just include all of the files. (It's only 5MB or so) NSIS has a zip archive as well as exe installer that includes the necessary files. (Or just zip up the installed directory from exe installer).
From my experience, NSIS does not need to be installed to work. I run a fleet of build servers that build NSIS-based installers, and they each just have the files extracted in a directory. The installer is never run on them. This should mean there are no DLLs to register or things like that.
Just make sure you are following whatever their licensing terms are - I have not reviewed redistribution/bundling of their files in another product, since that is not something I do.
For me, compact discs and these customized auto-start dialogs are somewhat outdated and waste...
However, I have to create such a dialog as an index for a CD consisting of a few PDF files. Making one to work on Microsoft Windows is quite easy. As there might be users from different platforms (Unix, Apple,...), the question raises how to offer them such a (auto-starting) dialog as well.
Java is of course an option, but I think it's overloaded and naturally too slow for this purpose.
Now, I think of a single webpage that will appear in the local browser. Using all these web standards this could a very creative, light-weight approach working on most systems.
Do you see any problems that might occur here? Probably, there is a different and more elegant solution to this issue?
I can't really recommend something precisely but I've seen lots of CD open a Adobe Flash dialog. It's also been a long time I've played around with flash but I think they're a setting in File > Publish that allows you to export to a dialog.
The CD auto-start is an autorun.ini file added to the root of the CD. You could create a folder on the CD named autorun or something. Insert all your Flash/HTML files then point the open parameter of the autorun.ini file to an HTML/Flash file.
Some documentation below (or Google “autorun.ini”).
http://support.microsoft.com/kb/818804
Notice however not all computer will have Flash installed by default.