Creating lanuchers in unity

Most of the postings I have seen on creating launchers in unity refer to the old way of making desktop launchers in previous versions of the gnome-shell.  In unity it is a little bit different.  For example say I want to add a launcher for my installation of Leksah, a nice Haskell IDE.   All I have to do is add a file to my applications directory in

/usr/share/applications

for this one I will call it leksah.desktop as the naming conventions for launchers specifies the .desktop convention

sudo touch /usr/share/applications/leksah.desktop

Now I just need to fill in the .desktop file with the following

[Desktop Entry]
Version=0.10.0.4
Name=Leksah
GenericName=Haskell IDE
Comment=Develop Haskell Software
MimeType=text/x-haskell;text/x-literate-haskell
Exec=/usr/bin/leksah
TryExec=leksah
Icon=/usr/share/leksah/pics/leksah.png
Type=Application
Terminal=false
Categories=Development;

and presto now when I pull up dash and begin to type in Leksah I see my new launcher.

I can also keep this in my favorites on the launcher panel as well.

Getting going with Equinox OSGi and Eclipse Juno

I started to get my feet wet today with Eclipse Equinox and OSGi.  I started with the example Toast application from the OSGi and Equinox book by McAffer.  I followed the instructions step by step for creating the example application with the exception that I am using the Juno integration build of Eclipse along with the latest org.eclipse.osgi and org.eclipse.equinox.* bundles.  Everything went quite smoothly until I reached the point of adding an activator to one of my bundles as an entry point.  The bundle started up and ran until the point at which the following exception showed up in the console:


Launching
Emergency occured at lat=3776999 lon=-12244694 heading=90 speed=50
!SESSION 2012-01-08 20:25:14.148 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_23
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Command-line arguments:  -dev file:/home/ryan/workspace/.metadata/.plugins/org.eclipse.pde.core/Toast/dev.properties -os linux -ws gtk -arch x86_64 -consoleLog -console


!ENTRY org.eclipse.osgi 4 0 2012-01-08 20:25:14.940
!MESSAGE Could not find bundle: org.eclipse.equinox.console
!STACK 0
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:296)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:624)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579)
at org.eclipse.equinox.launcher.Main.run(Main.java:1433)
at org.eclipse.equinox.launcher.Main.main(Main.java:1409)

When I tried switching back to the version of the org.eclipse.osgi package that came with Indigo all was well, but that was not the goal, I wanted to be up an running with the Juno bundles.  I realized that I needed to add the org.eclipse.equinox.console bundle, but this was a bit elusive at first.  Adding the packages exported by the org.eclipse.equinox.console bundle to my bundle's imported packages does nothing to fix the problem, and neither does adding the bundle itself to my bundle's required plugins.  I found this out by actually debugging the Equinox runtime to find that even when these packages or bundles are added as dependencies they are not loaded into the runtime.  The required changes must take place in the run configuration, or what effectively amounts to command line arguments to org.eclipse.osgi_3.8.0xxx.jar. So I added the org.eclipse.equinox.console bundle to my run configuration targets, got a few more complaints about missing bundles and ultimately wound up also adding org.apache.felix.gogo.shell and org.apache.felix.gogo.runtime.

What this does behind the scenes is creates the following config.ini file that is used in conjunction with the -configuration flag for the org.eclipse.osgi_3.8.0xxx.jar.

#Configuration File

#Sun Jan 08 20:50:34 PST 2012

osgi.bundles=reference\:file\:/home/ryan/workspace/org.equinoxosgi.toast.client.emergency@start,reference\:file\:/home/ryan/workspace/org.equinoxosgi.toast.dev.airbag@start,reference\:file\:/home/ryan/eclipse/juno/eclipse/plugins/org.eclipse.equinox.console_1.0.0.v20111215-1210.jar@start,reference\:file\:/home/ryan/eclipse/juno/eclipse/plugins/org.apache.felix.gogo.shell_0.8.0.v201110170705.jar@start,reference\:file\:/home/ryan/eclipse/juno/eclipse/plugins/org.apache.felix.gogo.runtime_0.8.0.v201108120515.jar@start,reference\:file\:/home/ryan/workspace/org.equinoxosgi.toast.dev.gps@start

osgi.bundles.defaultStartLevel=4

osgi.install.area=file\:/home/ryan/eclipse/juno/eclipse

osgi.framework=file\:/home/ryan/eclipse/juno/eclipse/plugins/org.eclipse.osgi_3.8.0.v20111210-1354.jar

osgi.configuration.cascaded=false

Which tells the osgi runtime to load the required components for console interaction.  I found this out by using the getprop command from the osgi> prompt.

With this out of the way we are now running happily

I hope that this helps someone trying to build an Equinox application in Juno. I have also tested this with openjdk-7 and all is well.

Moving on to more complex charge geometries

Now that PhysViz is successfully visualizing electric fields and particle traces for the simplest of charge geometries, the sphere, it is time to get a bit more complicated. In preparation for upcoming charge geo's; I decided that instead of going through the mathematical gymnastics and writing of countless mathematical helper functions for specific geometries, it would be best build in a cordinate superposition function set into the program in order to allow each charge geometry to effect the space around it as if it were square on the x-axis of its own coord-system.

The effort seems to be straight forward, the only differences that must be accounted for in translating between two superimposed coordinate systems should be displacement (cartesian) and delta_theta / delta_phi (spherical). I have made a first crack at writing these functions, displacement is easy, the sphereical change in angles is giving me a little trouble however. I am attempting to accomplish the angle calculations in the following manner:

delta_theta = arccos(dot_product(xy_normal_1, xy_normal_2))
delta_phi = arccos(dot_product(xz_normal_1, xz_normal_2))

where the postfixes 1 and 2 represent the two different coord systems.
Also keep in mind that this is the computer graphics coord system, where if sketched on a piece of paper y points straigt up, x points to the right and z points off the paper.

The system is producing some funny results right now, any ideas on some mathematical errors that I may be making?

Particle Traces!

Well the next step is here, PhysViz is now modeling +/- particle traces as they should behave in the electromagnetic environment created by the user. PhysViz allows for the user to define the start point for the particle, electric charge (positive or negative) and the trace length for the visual particle trace created. Check out the screen shots.

First Milestone

Well, I have been working on PhysViz in my off time from lead farming here in Afghanistan for about 4 months now and I am glad to say that the first milestone has been reached. The most basic functionality of the program is up and running!

The program takes input from the user through the windows forms GUI to create spherical em-sources (the most basic types of electromagnetic sources beyond a simple point charge) in the 3D environment and visualizes the representative electric vector field created by these charges. The field is also adapting seamlessly to changes in the environment made by the user in real time.

Here are some screen shots! (Click on them to see their full awesomeness)

Moving forward, I think I going to save new charge geometries for later (I am looking forward to the parabolic disc for focused em-fields), and the next step is going the be building the ability for the user to define charged particles in the view port that will move in an animated fashion according to the forces of the electromagnetic field that are acting on it. This is going to be a fun one!

A quick introduction to PhysViz

PhysViz is a scientific visualization program that uses high-performance computer graphics to visualize electric and magnetic fields produced by a user defined electromagnetic environment. The function of the program is best described by the following (work in progress) loose design specification.

PhysViz will:

• Provide an interactive 3D environment in which users can manipulate the camera viewing the environment to move and look in any direction, using a basic (x,y,z) axis at the center for bearing.
• Allow users to define Gaussian objects that have electromagnetic and geometric properties (em-sources).
• Allow users to define a vector field (em-field) that will represent the electromagnetic objects within the 3D environment. User definition of field attributes such as field resolution (vector samples per give unit of space), field size and location.
• The user may make changes to any em-source's electromagnetic or geometric properties, causing instantaneous adaption of the visual em-field to represent the changes.

The program is being developed in C# as a Windows Forms application with an embedded Microsoft XNA powered view port for the visualization.

Publish Post