I'd like to configure multiple profiles (from KDE's konsole) and I'd like to
open roxterm with multiple tabs, each with different profile.

how to do that?

I don't know what you mean by configuring multiple profiles from konsole.

roxterm's command line parser doesn't support opening multiple tabs with
different profiles, but you can do it with a script which runs a series of
roxterm --tab commands. Or you can open all the tabs you want then save your
KDE session.

I think there is a demand for something better than the current situation.
Unfortunately supporting multiple tabs with different profiles in one command
would need a lot of rewriting, affecting more than just the command line
parser. I thought I could add some sort of "private sessions" so you can save
and restore roxterm in a certain state independently of the rest of the
desktop.

I've had a read through the forum and this looks to be close enough to my request to avoid creating a dupe thread - I'm looking to replace XFCE4's terminal with roxterm, however it seems that I cant automatically set up a collection of tabs with particular titles like I have been able to do with the current terminal emulator and GNOME Terminal in the past.

E.g., here is how the main XFCE4 Terminal session is created:

===========================================================================

xfce4-terminal --maximize --title "Bash 1 - %w" --tab --title "Bash 2 - %w" --tab --title "Editing 1 - %w" --tab --title "Reading 1 - %w" --tab --title "Reading 2 - %w" --tab --title "Prog 1 - %w" --tab --title "Prog 2 - %w" --tab --title "Prog 3 - %w" --tab --title "Prog 4 - %w"

===========================================================================

With this you get 9 normal tabs ready to go. With roxterm I cant load multiple tabs at once, however I can use separate 'roxterm --tab' commands after the fact, although '--tab-name' seems to launch another roxterm window, so I can't actually name the tabs for their roles.

Am I going about this in the right way?

Thanks

There was a bug in --tab-name until recently (until 2.7.1 I think). I think you'd find the thread at https://sourceforge.net/p/roxterm/discussion/422639/thread/09ff8e98/ useful.

I am very sorry, I retardedly went off thinking I would be notified when a reply appeared here... I will check this out in the next slot.

I have done a quick check on this - the following commands all result (starting with no roxterm instance) with one tab with the last name:

==========================================

roxterm --title 'Test' -n 'Tab 1' -n 'Tab 2'
roxterm -n 'Tab 1' -n 'Tab 2'
roxterm -n 'Tab 1' --tab -n 'Tab 2'

==========================================

I have v2.7.1 currently (pulled off Debian experimental), I will compile it direct from the latest code later. Also, do you want me to raise this as a bug rather than this thread?

You have to open each tab with a separate command, and I don't want to fix that because I'd have to write a much more complicated command parser. Unfortunately if you use separate commands in a script there's a race condition so the second command usually opens a new instance because the first one isn't ready to handle it yet. --fork is supposed to prevent that, but apparently it doesn't work, according to
https://sourceforge.net/p/roxterm/discussion/422639/thread/09ff8e98/. I should be able to fix that and will give it a try.

OK, understood. There is no need to be pressed to do this on my part - XFCE4 Terminal works for me, its just that I think roxterm is better as a long-term solution for terminals. I will keep tabs on this thread.

...its just that I think roxterm is better as a long-term
solution for terminals.

Just to close the loop on this, and sum up what was learned in the threads Tony linked to, it's pretty easy to make this work today (even with the bugs) with a bit of scripting. The simplest version looks like:

roxterm -n tab1 &
sleep 20
roxterm --tab -n tab2
roxterm --tab -n tab3
...

You can probably get away with less than a 20 second sleep, but you'll have to experiment to see what works on your system.

A more sophisticated version that delays the minimum possible would look something like (this assumes POSIX shell (bash)):

roxterm -n tab1 &
until qdbus | fgrep -q roxterm; do sleep 1; done
roxterm --tab -n tab2
roxterm --tab -n tab3
...

Once the bugs are fixed, that should turn into:

roxterm --fork --tab-name tab1 &
roxterm --tab  --tab-name tab2
roxterm --tab  --tab-name tab3

-Tom

roxterm --fork --tab-name tab1 &
roxterm --tab --tab-name tab2
roxterm --tab --tab-name tab3

You shouldn't use & in conjunction with --fork because the shell will continue asap whereas --fork is supposed to wait until the dbus service is ready before returning from the foreground process to the shell. You haven't been using & all along have you? I'm hoping --fork isn't bugged after all!

You shouldn't use & in conjunction with --fork
You haven't been using & all along have you?

I only tried --fork briefly. (I don't think that option existed when I first created my script.) But I had to consult the revision history to see what syntax I used when I tested it:

% rlog bin/start_term
[...]
revision 1.8
date: 2013/03/13 06:11:05;
[...]
Switch from & and sleep to using --fork.

% rcsdiff -r1.7 -r1.8 bin/start_term
=======================================
7,10c7,9
< roxterm --tab-name Fringe &
< sleep 20
---
> roxterm -n Fringe --fork
> #sleep 20

.

I'm hoping --fork isn't bugged after all!

Sorry. Apparently I did it correctly. I just wrote it incorrectly in my hypothetical in the prior posting.

I have now knocked up a script to launch roxterm sessions based on what Toms said, the following works:

# Launching initial window
roxterm --tab -n "Bash 1 - %s" &
disown %

# Waiting until roxterm has registered a dbus service (i.e. it is ready to take further commands)
until qdbus|grep -q roxterm
do
    sleep 1
done

# roxterm is ready for more tabs - launch them
roxterm --tab -n "Bash 2 - %s"
roxterm --tab -n "Editing 1 - %s"
roxterm --tab -n "Reading 1 - %s"
roxterm --tab -n "Reading 2 - %s"
roxterm --tab -n "Prog 1 - %s"
roxterm --tab -n "Prog 2 - %s"
roxterm --tab -n "Prog 3 - %s"
roxterm --tab -n "Prog 4 - %s"

Thanks :)

I've just tried to fix --fork; please can you pull the latest git and see if your scripts work without qdbus now.

Can you push that to a PPA or provide a deb (64-bit)?

I've built Roxterm from git before, but it usually takes more time to install build dependencies and debug the build process. (I haven't built Roxterm from source since installing a new OS last Fall.)

Thanks - I ran this 5 times and in all cases the correct tabs were created.

Previously with the qdbus script, when the launcher script ran as part of the automatic application startup after logging in, roxterm failed to keep all tabs in one window and so I ended up with many terminal windows.

Now with the fork version, testing now I get just an 'Editing 1' window, no other tabs.

Since testing involves killing my session, I won't be repeating this often (this machine and my session is supposed to remain up).

...with the qdbus script...roxterm failed to keep all tabs in one window and so I ended up with many terminal windows.

So you're saying the qdbus hack failed to work as intended?

I've implemented it locally, and have rebooted since doing so, and it appears to have worked for me.

I would double check that your conditional is working as you expect. Test it separately, using both 'roxterm' as the search string (when Roxterm is runing) and some other string not found in the qdbus output, and make sure in the latter case that it doesn't return (continue) immediately.

If it is in fact finding a "roxterm" Dbus listener and yet Roxterm is still launching new windows, then there is a bigger problem.

I wrote:

I've implemented it locally, and have rebooted since doing so, and it appears to have worked for me.

Apparently I was either lucky or misled by my file timestamps. I just rebooted and this time the qdbus hack failed and all tabs opened as separate windows.

Tony Houghton wrote:

I think there's a race condition somewhere else in roxterm after it's started the dbus service...I think I've found the real problem now...

Ah...I'll see if I can grab the git version later tonight and try it.

Scratch that - had to reboot again to try to debug a radeon issue and I get 9 windows created - so it still breaks as normal at startup.

If I add a similar script to my desktop start-up I can reproduce this now, both with the new and old code, and even when waiting for qdbus. I think there's a race condition somewhere else in roxterm after it's started the dbus service, maybe something to do with the window being realised. If the problem was only with dbus I'd expect the script to block on at least one of the non-fork roxterm commands until the resulting window is closed. I have experienced that in some tests, but the usual behaviour is that all the windows open at once.

I think I've found the real problem now, Omega, can you test git again?

can you test git again?

I built from git and modified my startup script to remove all the sleeps and other hacks, and went through 2 boot cycles (testing a graphics driver issue) and both times Roxterm launched tabs correctly.

So I think you might have found it.

The build from git was pretty painless, though until I tried, I wasn't sure I was following the right steps because I had to sift info out of paragraphs. I recommend listing the steps that will work for most users with current systems as a succinct set of bulleted steps, and then have the verbose info below for atypical situations.

My build from git steps - on Ubuntu 12.04 - went as follows:

% cd /usr/local/src
% git clone git://git.code.sf.net/p/roxterm/code roxterm-code
% cd roxterm-code
% sudo apt-get build-dep roxterm
% dch
% debuild -b -uc -us
% cd ..
% sudo dpkg -i roxterm_2.7.1.26-1_all.deb roxterm-common_2.7.1.26-1_all.deb roxterm-gtk3_2.7.1.26-1_amd64.deb

(Was running dch necessary? I didn't examine debian/changelog before, but dch prompted me to add an entry below one you had already written for 2.7.1.26-1 that looked valid, so I didn't save any changes, though git describe shows 2.7.1-28-g6d9c3a1. no automation to handle this?)

It felt like I had to do more work than necessary to extract that from the paragraphs at the end of Help/en/installation.html.

Speaking of which, the HTML help file is beautiful, but the basics for installation should also be presented in the INSTALL* file in the project root in plain text, where a console user can easily view it. (lynx --dump Help/en/installation.html > INSTALL would do the job.)

-Tom

Certainly. I wonder how I installed before, since I don't remember maitch...

I have tried to build but get the following error:

=======================================================================

$ ./mscript.py build --parallel 8

make[0]: Entering directory "/home/omega/files/source_code/roxterm/roxterm-code/build"
Traceback (most recent call last):
File "./mscript.py", line 402, in <module>
trans_rules = PoRulesFromLinguas(ctx, **args) + \ File "/home/omega/files/source_code/roxterm/roxterm-code/maitch.py", line 2056, in PoRulesFromLinguas
kwargs.get('podir'), kwargs.get('linguas'))
File "/home/omega/files/source_code/roxterm/roxterm-code/maitch.py", line 2036, in foreach_lingua
"but no corresponding po file found" % (linguas, l))
maitch.MaitchNotFoundError: Linguas file ${TOP_DIR}/po/LINGUAS includes fr, but no corresponding po file found

=======================================================================

This is from a fresh pull.

The po files accidentally got removed from git; it doesn't handle them very well. I've added them again so you can either pull them from git or run mscript configure again with --disable-translations. And I think you need --parallel=8 ie '=' instead of a space.

Thanks - this now builds - yes, the '=' was needed for this script.

Unfortunately checkinstall chokes on the installation, so I have put this testing on my list of things to do (working on other stuff atm).

I have now tested this - not only did it start up correctly, the git install has visually much more efficient tabs (smaller), that actually highlight when in use... so I guess its linked to GTK2 rather than the GTK3 mess! Result!

Thanks for fixing.