multiple instances of osso-xterm?
 

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!

Re: multiple instances of osso-xterm?
 

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?

Re: multiple instances of osso-xterm?
 

@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.

Re: multiple instances of osso-xterm?
 

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...

Re: multiple instances of osso-xterm?
 

@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?

Re: multiple instances of osso-xterm?
 

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.

Re: multiple instances of osso-xterm?
 

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...

Re: multiple instances of osso-xterm?
 

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?

Re: multiple instances of osso-xterm?
 

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.

Re: multiple instances of osso-xterm?
 

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...:rolleyes:

Re: multiple instances of osso-xterm?
 

Oh, certainly! There are indeed many different kluges you can use to work around this problem, such as leaving two windows open constantly, or going to the alpine window and then opening a new window from its menu bar, or using "screen" to avoid the entire question of windows, etc.

It's just that you just can't open a second window from the desktop. You have to find some other way to do it.

Re: multiple instances of osso-xterm?
 

xterm is a graphical, interactive, program. You don't need xterm to run a shell script or any program.

I understand you may not want to open, say, modest two times. But xterm?

Re: multiple instances of osso-xterm?
 

I'm happy now with the term-app-launcher.

Out of "hate", I will spend some time making a nice config file for mrxvt and then I'll just stop using osso-xterm (heck, I might even uninstall it..)

Re: multiple instances of osso-xterm?
 

usually i do open a 2nd X terminal (with the New option) when in the middle of writing some complicated command and not remembering where a certain file may be and i'm too lazy to type Ctrl+A, # and Enter to "save the line" and run a find cmd in the same window rather then a 2nd

something for command line freaks i guess :D
i wouldn't remove it however as system scripts most likely depend on it & wouldn't run properly anymore without it :(

Re: multiple instances of osso-xterm?
 

I've never seen xterm showing up while booting :)

AFAIK osso-xterm is just another user application. Busybox is a different thing, obviously.

But no, I won't apt-get remove osso-xterm. I'll just see if the other alternatives (like mrxvt) are better suited for me.

Re: multiple instances of osso-xterm?
 

Wait. People use the alpine port I put in the repos? Seriously? That happens? Or did you compile your own?

For the record, I just open new x-term windows with Shortcutd, just using the "Custom shell command" option for the half-camera-button press. With the command: /usr/bin/osso-xterm ""

That always opens new instances of x-term just fine. Idk if that would work with your situation, but if you were willing to map the opening of blank x-terms to your camera half-press (don't worry, it doesn't trigger when you're in actual camera programs afaik), then you should be able to open normal x-term windows unimpeded.

I'm currently fiddling around the the .desktop file of x-term, and looking at how other command-line programs (TestDisk, PhotoRec, Asterisk) set up their .desktop files. Will edit this post (if no one else has posted since then, in which case I'll make a new post) if I make some sort of meaningful breakthrough.

- Edit -

Progress. I just noticed (after deleting/changing some lines in the osso-xterm.desktop file), that if you execute that desktop file, the OS is basically always going 'frak you, I'm taking you to an old x-term window' - but if you copy that same x-term file over to, say new-xterm.desktop, it opens new windows of x-term just fine. Now I have to roll back the changes I did to the original x-term desktop file, and then see what, if any, changes are necessary, to the way the original osso-xterm.desktop file was written, or if it was simply the use of a differently named desktop file then some special, protected one, that did it.

- Edit 2 -

Okay, simply copy-pasting the exact, original osso-xterm.desktop file to a new .desktop file doesn't work. So something about the changes I did was necessary. Will report back shortly. (BTW, I still have no idea what effect this has on desktop shortcuts, since I don't use any, but I imagine the changes would carry over from the app-menu/launcher.)

- Edit 3 -

Got it. It was the X-Osso-Service=xterm line that was preventing the copied file from working right. Just delete that, and your new xterm .deskstop file will open new x-term windows. Still not sure why removing it from the original file didn't work (but that might be because something needed to be restarted that keeps track of these things. There's also a weird symlink at /etc/others-menu/0301_osso-xterm.desktop pointing to the actual osso-xterm.desktop file.

For those who don't know, .desktop files are in /usr/share/applications/hildon/
Well, the ones for the app launcher/menu/desktop go there. The ones for status menu and the like have other subdirectories inside the applications directory.

I will post a more proper how-to once I've ironed out the details (like whether or not you can just force the original osso-xterm.desktop file to behave as desired)

- Edit 4 -
Quick clarification - when you edit the .desktop files, after you've saved the changes, you'll notice a freeze for a few seconds - this is because the whole desktop environment now has to reevaluate what app it needs to put where and what they do, etc. So don't panic.

- Edit 5 -

The above is confirmed as working when used as a desktop shortcut as well. (Am I really the first person who's figured this out, or am I just reinventing the wheel here?)

- Edit 6 -

In order to figure out what that symlink to x-term's osso .desktop file had to do with anything, I deleted the symlink. Then I deleted the line X-Osso-Service=xterm from osso-xterm.desktop. Using that shortcut still redirected to an existing console window. Went to reboot. N900 behaved oddly (just kept blinking while light, even though aside from that it was basically unresponsive, indicating possible hang somewhere late-boot {edit: late-shutdown, not late-boot} maybe). Pulled battery. Booted. Got to my /sbin/preinit shell prompt, looked inside /etc/others-menu/ folder - no symlink to osso-xterm's .desktop file was in there at the time. Exited shell prompt, boot continued.

Small oddity with the new-xterm.desktop desktop shortcut - right after boot if was failing to open new terminal windows until after I had opened one from the app menu (don't remember now whether it was the just the new-xterm, or both osso-xterm and new-xterm menu icon(s) that I pressed). After that, started working right again from desktop shortcut as well.

Rebooting again after having added the X-Osso-Service=xterm line to osso-xterm.desktop, to see what happens (like if the symlink gets recreated).

- Edit 7 (technically 8 if you notice tiny typo fix edit in Edit 6) -

Shutdown worked fine, previous shutdown glitchiness was probably unrelated anyway. No symlink as of /sbin/preinit console - which makes sense. Nothing other than kernel loading happens by the time /sbin/preinit is executed to the point where my shell prompt resides. Which means symlink didn't get restored upon shutdown by some system process, I would wager.

Okay, again, right after boot, first click on the new-xterm.desktop desktop shortcut opens an x-term, but the next click doesn't. Clicked on the osso-xterm.desktop app menu icon. Got redirected to existing terminal. Clicked desktop shortcut for new-xterm.desktop again, and new x-terminal window opened just fine.

Still no symlink in /etc/others-menu pointing towards osso-xterm.desktop, suggesting that symlink is installed by something else entirely and is not dynamically created by anything. And it certainly doesn't seem to effect the fact that the osso-xterm.desktop icon seems otherwise hardcoded to not open a new xterm window, even if you remove the X-Osso-Service=xterm line from that file. Restoring symlink. No change to behavior of either osso-xterm.desktop or new-xterm.desktop.

Rebooting. - Edit 8 -
Before rebooting noticed another odd behavior. Closed all terminal windows. Tried to open multiples from desktop shortcut. Didn't work after the first. Worked after opening another from the menu icon. Closed all xterm windows again, tried opening multiples from the menu icon. Also didn't work after the first, until I opened one from the desktop shortcut. (Which is really odd since they both are of the same new-xterm.desktop file.)

Now rebooting.

- Edit 9 -

Just noticed something. TestDisk, PhotoRec, and Asterisk behavior is similar to my current new-xterm.desktop - Tthey won't open a second instance of itself unless you trick it by opening one from desktop shortcut, one from app menu icon. However, it seems you can sometimes get them to start opening new instances IF you have an instance open and another is trying to load when you try to open a third.

Going to keep fiddling.

- Edit 10 -

Hmmm... I think I have misunderstood how [new-xterm/photorec/testdisk/asterisk].desktop, manage to open second copies.

It's not a matter of them opening a new window succesfully when there's another instance trying to open. But seems to be more of a the first click,that would attempt to open a duplicate window fails, but then if you wait until it has finished failing, the next click that would attempt to open a duplicate window, and all after that, work just fine, unless you've closed all your x-terminal windows, in which case it repeats (first window opens fine, second fails, but once it has finished failing, all other attempts work fine).

That is, of course, on the same icon - if you do one on the desktop shortcut and one on the app menu icon, or even one on the osso-xterm.desktop shortcut/menu-icon and one on the new-xterm.desktop shortcut/menu-icon, then all attempt to open windows work fine. Seriously, why did the Nokia team in charge of Maemo 5 have to make it so damn hard to open multiple instances of the same program? *Facepalm*. Because it seems to me like the only reason why it's possible to do, is thanks to their way of blocking it being buggy.

Re: multiple instances of osso-xterm?
 

I'm going to keep editing the above post as I figure this out, but regarding reinob's original concern, you could just make a .desktop file for alpine specifically, like asterisk, testdisk, and photorec do. Those open in their own window, even if you have x-term open. I'm stupid, since the aforementioned will open in their own windows if opened after x-term is already open, but stock x-term icon will redirect to their windows if they're already open.

Re: multiple instances of osso-xterm?
 

Okay, as present, I don't think I will be getting much father with this. So, as per the above post, where I was rambling with the bunch of edits, is a solution available, that I think would work for reinob's desired behavior in the original post. It's not ideal for what I think we would all like (gets 100% perfect new-window-on-every-click of the x-term desktop/menu icon behavior), but it does get the desired behavior stated in the first post of "you can open alpine from one desktop shortcut, and then open xterm one of the normal ways, and not have it automatically redirect to the alpine window".

Copy /usr/share/applications/hildon/osso-xterm.desktop to /usr/share/applications/hildon/[whatever you want to call it].desktop

Edit the new .desktop file to remove the line:
X-Osso-Service=xterm

Now, so long as you use the new x-term icon instead of the old, much of the time, it will open a new x-term window.

The ONLY exception will be if you have no xterms open, you open the first one from either the desktop or menu icon to that .desktop file, and then the second one ALSO from that SAME icon, in which case, if you wait until that opening fails, and try again, it'll open it again smoothly from there.

But if you open a terminal any other way for either the first or the second x-term window (such as by opening alpine through another shortcut or widget), you'll have no problems and they'll open in different windows just fine.

From then on, until you've gotten to a state where you've got no X-Term windows open at all once again, pressing the new x-term icon will open a new window as one might expect. (I would imagine restarting hildon-home or hildon-desktop might reset this, but I didn't test.)

"But Mentalist Traceur, how will we ever differentiate between the two x-term icons?" you might be asking? Well don't worry mere mortal, for I have a solution:
If you want to edit either of the icons to have a different image, that's right inside the .desktop file, on the line that starts with "Icon=". Just change the name to the name (without the file extension part) of your desired icon, so long as it's located either in /usr/share/icons/hicolor/48x48/hildon/ or in /home/user/.local/share/icons/hicolor/48x48/hildon/ (some other folders might work too, but I would think those are the only ones).

"That won't do, Mentalist Traceur, I hate the old osso-xterm.desktop with a burning passion and I wish to never see it again", you cry out, years of anger at the inability to conveniently open multiple x-term windows boiling forth? Well, calm yourself, for soon your lust for vengeance shall be quenched:
If you want to hide the icon of the original osso-xterm.desktop, you have a few options:
Edit the original osso-xterm.desktop file to hide it by adding the line:
NoDisplay=true
Delete the osso-xterm.desktop file. (Haven't tested what happens, probably no problems)
OR, if you want reinstalls of the package osso-xterm (such as by updates by CSSU to that package) to not force you to have to re-edit/delete that file, you can either
Edit /home/user/.config/menus/hildon.menu to contain the following lines:
<Exclude>
<Filename>osso-xterm.desktop</Filename>
</Exclude>
...right after the <Include>{Something}</Include> lines. (If you already have an <Exclude>{Something}</Exclude> section in there, just stick the <Filename>osso-xterm.desktop</Filename> line in there.

If you don't have that file, edit
/etc/xdg/menus/hildon.menu
However, if you don't have the former, I would copy-paste hildon.menu from the latter to the former location - the one in .config takes precedence, and if you mess up and get a blank app menu as a result, you can delete the one in .config and try again.

As an aside to the people who use my alpine port - do people want me to include an alpine.desktop file within the packaging? I figured people don't care, but I wouldn't mind getting it in there.

Re: multiple instances of osso-xterm?
 

@Mentalist Traceur,

Thanks a lot for your experiments. For now I'm happy with the app-term-launcher, but I'll try to experiment with osso-xterm.

Couple of things,
/etc/others-menu is a relic from previous Maemo versions. You can wipe out the folder if you like.

Re. alpine: I'm using the port from http://home.mminternet.com/delaroca/index.html/. It's probably identical to your port, but I installed it before your announcement.

Actually, some day I'll post my setup with dovecot/offlineimap/alpine (+ modest working OK) including some settings so as to minimize power consumption of dovecot and offlineimap, etc.

I'm slowly and randomly removing my dependence on GUI applications.. :)
(someday I'll write a CLI dialer, just for the fun of it).

Re: multiple instances of osso-xterm?
 

:p

Maybe you can jump in/start here?

Re: multiple instances of osso-xterm?
 

Attached is .mrxvtrc for mrxvt if you want to try alternatives. It might not be best for switching between many instances as any ctrl-backspace or even notification popping up will make mrxvt loose focus/refresh. Lock/unlock fixes it. Found it most useful to achieve real 80x25 for compatibility ('mrxvt-full -name FullScreen -e ssh xxx@yyy.com' will get you a nice 80x25 ssh session for example). Also attached is Dejavu Sans Mono font for the fullscreen setting.

edit: just to clarify, refresh-loss only happens when in fullscreen mode. If you run your console apps in windowed mode no problem when switching/notifications popping up.