open multiple profiles at once?

[Tony Houghton]

You can force it to use GTK2 by adding --disable-gtk3 to the configure options, or if using Debian packages, use roxterm-gtk2 instead of roxterm-gtk3.

[Omega Weapon]

Right, this has been failing again for some time so I am trying to look into this now. Its trivially recreatable on my VM - if I launch my main session and a separate roxterm instance running htop at the same time, the main session fork call fails:

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

(roxterm:14951): ERROR : Child failed to signal parent for --fork: Bad file descriptor

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

The main session:

'/home/omega/files/bash/roxterm_session_launcher.bash' standard_session:

roxterm --fork --tab -n "Bash 1 - %s"

# 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"

The htop session:

roxterm --title 'htop' --execute bash -c 'sudo htop'

In reality I have 3 separate roxterm sessions start up when I log in, so this is bad.

[Tony Houghton]

The htop session is probably racing with the main one. There isn't an easy way to handle that, but adding --fork to the htop one might help. If they're going to be launched at the same time they really need to be launched from the same script to make sure things work smoothly. Can't you do that?

[Omega Weapon]

I have done more testing and I have found that adding '--replace' to the roxterm --fork calls stops the pipe reading failure - adding a delay to launching the session startups then allows them to start up correctly in the test VM (without the delay the additional tab invocations naturally end up in the wrong session).

About using one script - true, however the script isn't really a startup script but a 'launch named sessions' script that gets called adhoc other times.

Now that the VM works, I went back to the main machine and did the same thing - but then I hit up against the original problem - independent of htop and any other sessions launched, the main 9 tabs session repeatedly fails to end up with one window. Its almost like there is a timelimit for tabs to be added on, and then it spawns another. However the last two times, the first window had just the one tab and the second window the rest, so it can't be that either...

I'll see how I can fight this now.

[Omega Weapon]

Reload tab has destroyed my reply.... I have given up for today, can't fathom how roxterm works at startup - everything is obvious when it is launched later on (roxterm_init is called etc etc), but it doesn't behave that way at startup.

Will be back on this on Saturday.

[Omega Weapon]

Many hours and days later, I have finally cracked this project. My time was seriously wasted by glib bricking the normal printf somehow - once I finally realised and changed to g_print, it took me another day to find the actual issue (that so far only happens when roxterm starts up on login).

The problem is in roxterm.c:roxterm_launch, and how the workspace result from x11support_get_wm_desktop is used. global_options_workspace is set to -1 in this program to respresent an unset/invalid workspace (I'm presuming) - this is wrong, -1 is actually a valid return value meaning the window is visible on all workspaces (http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html , see '_NET_WM_DESKTOP' and the value 0xFFFFFFFF, which is -1 as an int). Along with this, the subsequent 'if ((int) workspace == global_options_workspace)' needs to also check for -1 to match against this extra value.

I have devilspie running which detects roxterm windows and pins them to all workspaces, but it isn't instant and the program segfaults regularly leading to a 1 minute delay in the wrapper script before relaunching - causing the semi-random failures I see with roxterm (rather than permanently screwing up).

When all roxterm windows report -1 for workspace, a new maximised window is launched - sometimes one or more of the windows isn't yet pinned (perhaps theres also some interaction with new tabs being added to a window), and a tab correctly attaches to a window.

Shall I make a patch for this (outside of my hacked up version)?

[Tony Houghton]

I've tried to fix this by using 0xfffffffe as my "undefined" value and recognising 0xffffffff as meaning all workspaces in the if statement as you suggested. Please can you pull from git and test.

[Tony Houghton]

PS I use a browser extension called Lazarus to deal with SF losing what I've typed when trying to post something, There are versions for at least Chrome and Firefox.

[Omega Weapon]

Sourceforge really needs subscribing to threads. I have done 4 login and startups in a row - each time 9 tabs were set up in one window correctly, so it works.

Thanks for the note about Lazarus BTW, I am vaguelly aware of it - just this incident it would have been helpful with, not enough to keep it installed permanently mind.