I'm trying to figure out how to be able to open multiple instances of osso-xterm via its shortcut (i.e. not via its own menu "New" option).

I've looked in /usr/share/applications/hildon/osso-xterm.desktop, which includes "X-Osso-Service=xterm"

In /usr/share/dbus-1/services/osso-xterm.service I don't see anything that would indicate that only a single instance is allowed.

So it's probably something being done my maemo-invoker (osso-xterm is a symlink to maemo-invoker)

Are there any configuration options for maemo-invoker? or is it hard-coded to only allow once single instance (may make sense for calendar, media player, etc. but surely *not* for osso-xterm!).

[Note that running directly /usr/bin/osso-xterm.launch produces a segmentation fault]

I'd be grateful for any pointers!

Ctrl Shift and X opens multiple instances.
Also "/usr/bin/osso-xterm" will open another instance like the new button.
Is this what you mean?

@sixwheeledbeast,

Thanks for the useful reminder . My problem is this:

I have a shortcut on my desktop/app.menu for running alpine through osso-xterm (so command line is like "osso-xterm -e /opt/bin/alpine").

I have alpine open that way and then I click on my desktop shortcut for xterm then maemo just focuses the existing xterm/alpine window, instead of opening a new instance of osso-xterm.

I find using ctrl-shift-X inconvenient, and would like the osso-xterm shortcut to behave like a normal program. I suppose it all has to do with the d*mn#d maemo-invoker/maemo-launcher crap.

I guess if I don't find a solution for this I will have to either (1) use another terminal (mrxvt is nice) and/or (2) recompile osso-xterm without "launcher" support.

Hmm. So, does that mean that "osso-xterm -e /opt/bin/alpine" run from maemo-launcher has different behavior than "osso-xterm -e /opt/bin/alpine" run from xterm itself? Then perhaps running somethng like:

osso-xterm -e "osso-xterm -e /opt/bin/alpine"

from maemo-launcher would have something closer to the desired effect, as the second osso-xterm would presumably follow the command line behavior. (I guess you could put the second xterm command in a script or something, and so have the first window exit after opening the second one.)

(I really don't know anything about maemo-launcher, so please ignore me if this is a dumb idea...)

Edit: Ah, I see, what is needed is for Alpine to not be visible to the maemo-launcher, otherwise it'll keep getting picked up when you run xterm from the gui. My idea doesn't help much with that...

Edit2: On the other hand, if you could turn the launcher command for the terminal into something like "osso-xterm -e osso-xterm", that would presumably bypass the launcher behavior as well...

@Copernicus,

Thanks for your ideas. I'll try to experiment with that and see if it works around the problem.

But in any case osso-xterm (in /usr/bin) is actually a symlink to /usr/bin/maemo-invoker, which in turn asks /usr/bin/maemo-launcher to actually execute /usr/bin/osso-xterm.launch

[RANT] No, obviously a simple executable didn't cut it for Nokia. They needed like 3 leves of indirection. Thanks for nothing. [/RANT]

The problem is that the "actual" executable is osso-xterm.launch, which can only be launched by maemo-launcher (essentially: fork, dlopen, main).

So if maemo-launcher decides that only a single instance of osso-xterm.launch can be active, there's no way around it.

Note that (I just discovered) the "New" option in osso-xterm will *NOT* run a new instance of osso-xterm, but will create a new pseudo-tty (pts/1, pts/2, ...) and run sh on it (fork/exec). But osso-xterm.launch (which is actually maemo-launcher) itself will stay there alone.

Note (I also just discovered), CTRL-SHIFT-X does the exact same thing as using the "New" option under osso-xterm (obviously, if no osso-xterm is active, it will maemo-launch it

Add.: Note (for completeness sake). running "osso-xterm" from the shell (i.e. from within osso-xterm) will NOT launch a new instance of osso-xterm, but will do exactly the same as the two other options above.

So I rephrase my original question: How the f*ck do we control maemo-launcher so that it allows multiple instances of, at least, osso-xterm.launch?

OK, I found at least a workaround: term-launcher-app

The function is equivalent to osso-xterm but is independent on it (but obviously uses libvte as well).

So I put this on my alpine.desktop
Still, I'd be interested if anyone knows a way of "disabling" or at least configuring maemo-launcher on-device so that it allows multiple instances of a set of programs.

Hmm; actually, if I was absolutely paranoid about memory usage, and wanted to ensure that none of the multitude of Unix scripts and shells out there opened unnecessary copies of system utilities, this is probably the first solution I would think of -- redirect absolutely every system utility request to my own manager, and from there choose how to redirect the request.

But yeah, it's a pain if the launcher doesn't do what you want it to do...

did you try ?
this way the command executed (in your case alpine) will be launched in the background and leave your prompt available

a ~2½ megabytes memory used per X Terminal window open, it makes sense to try and keep the user from opening too many of'em, doesn't it?

As I understand it, the problem in this case is to set up a desktop shortcut for alpine that will not interfere with a desktop shortcut for xterm (and vice versa). So far as I can tell, if there is an open osso-xterm window, there is no way from the desktop to open a new osso-xterm window; all such attempts will be redirected to the already running window.

Thus, if you have an xterm running alpine, and you want to open a new xterm window, you cannot do so from the desktop. The behavior of maemo-launcher makes this impossible.

2 is the smallest instance of several...
if the 1st one remains available as a "terminal" to enter commands, maybe there is no need for a 2nd one?
and it saves 2½ MB RAM...