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.

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?

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

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
i wouldn't remove it however as system scripts most likely depend on it & wouldn't run properly anymore without it

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.

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.

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.

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.

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

Maybe you can jump in/start here?