I upgraded to 2.6.4-1ppa1precise1 (as the version implies, from the Ubuntu PPA) recently from whatever is the version in the 12.04 official repositories, and on restart with my usual startup script noticed the following:
-All tabs were opened as separate windows. The core of the script looks like:
In the past, this has worked as expected. The 2 second sleep is adequate for the roxterm process to start, and subsequent invocations with --tab open new tabs in the original window.
I closed all the windows except for the first one created and ran my startup script from that and it created the tabs as expected in that window.
Do I need a longer delay with this version for some reason? Is there a deterministic way of doing this? (I'm sure I could hack something together with xdotool, but how about a command line option?)
-the --tab-name option appears to be broken. All of my tabs are named the same as my window, which is the title passed to the first instance.
I thought maybe the command line syntax changed, but --help documents the same API, and no errors were reported to the console when I ran my script to launch Roxterm. Bug?
-all tabs have a number prefix on the title:
foo 2. bar 4. baz
Is there an option to disable that? (I haven't gone huinting through the GUI yet.)
-Tom
Last edit: Tom Metro 2013-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, for some reason I didn't get round to releasing 2.6.5 or 2.6.6 in my
PPA. A new "upstream" version is long overdue anyway. But I don't think 2.6.6 would fix this for you anyway, I'm also experiencing some odd behaviour with the --tab and --tab-name options. --tab on its own seems OK, but --tab-name seems to behave like --tab, whereas -n works correctly. If you replace your --tab-name options with -n does that fix it for you?
The tab number prefix is an option, it's in the Tabs section of the profile, near the top-right of the dialog.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been waiting months for this reply...assumed you were just busy. Turns out Sourceforge apparently was dropping emails. No Roxterm forum emails sent betweeen my last tmux posting on 12/14 and a message from Jim Paris on 1/11. Weird. [Looks like I wasn't subscribed to Help.]
I'm also experiencing some odd behaviour with the --tab and
--tab-name options.
Good that it is reproducible.
does [-n] fix it for you?
Yes.
The tab number prefix is an option...
Ah, I see. Any idea why that would have gotten enabled? It wasn't set by me.
I originally wrote:
Do I need a longer delay with this version for some reason?
I ended up boosting the 2 second delay to 20 seconds, and that relibly resolved the problem.
Is there a deterministic way of doing this?
I saw you menion --fork in abother thread. That sounds like exactly what I want if it only returns control after the first instance is prepared to receive D-BUS messages.
Last edit: Tom Metro 2013-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I overlooked this as one of the things that should be fixed before releasing 2.7, so it's a good job I hadn't quite got round to the release yet. Please could you use the ticket system in future, because it makes it easier to keep track of bugs.
I think you have two symptoms and two or three solutions:
Problem 1. Tabs opening in separate windows despite --tab.
Problem 2. Incorrect tab names (--tab-name being overlooked).
Solution 1. Increase the sleep delay.
Solution 2. Use --fork.
Solution 3. Use -n instead of --tab-name.
Do all three solutions (on their own, not used together) fix both problems or just one or the other?
I made the tab numbering option on by default. I sometimes do that with new options eg if I think more people will like it than not. Having the numbers visible is a handy cue for fast switching with Alt+<n>. I thought there were mnemonics in the menu items for that, but apparently not. I also seem to have just discovered a bug in GTK3 wrt showing mnemonics when you press Alt https://bugzilla.gnome.org/show_bug.cgi?id=695775.
Last edit: Tony Houghton 2013-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you have two symptoms...
Problem 1. Tabs opening in separate windows despite --tab.
Correct.
Solution 1. Increase the sleep delay.
Tested and confirmed to work.
Solution 2. Use --fork.
I've updated my script to use this instead of a delay. I can't effectively test it without shutting down my current Roxterm instance, which is disruptive. (I tried opening a new window, and then launching the script from there, which opened a 3rd window, and created some sort of an endless loop with the subsequent programs Roxterm launches per my command lines. I don't get why there would be a loop, but I killed off all the new instances. So I can't confirm it works just yet.)
I'll post a follow-up after I've been able to test it.
Problem 2. Incorrect tab names (--tab-name being overlooked).
Correct. Apparently unrelated to Problem 1.
Solution: Use -n instead of --tab-name.
Tested and confirmed to work. I've updated my script to use -n.
Problem 3. was the tab numbering, which was resolved by altering the setting.
Do all three solutions (on their own, not used together)
fix both problems or just one or the other?
No, but any expectation that they should? For example, increasing the delay didn't fix the labeling of tabs.
I made the tab numbering option on by default.
Ah...
Having the numbers visible is a handy cue for fast switching...
Sure. A feature I don't use. The change probably would have been less jarring had the tab labels been as expected. Though I still would have turned it off. The numbers take up space and serve no purpose for me.
Maybe add an option to the tab context menu to enable/disable the numbering? Or is that abusing the menu with settings that are rarely changed?
a bug in GTK3 wrt showing mnemonics
When I press Alt, the underlined letters appear on the menu bar items, yet when a popup menu is displayed, pressing Alt does nothing. That? (Same behavior in other GTK apps I'm running. Firefox shows underlines always.)
Please could you use the ticket system in future...
Absolutely. I actually hate reporting bugs via forums. Way too difficult to tell if the same issue has already been repprted.
I chose the forum option here because I was seeing a bunch of issues simultaneously after a version upgrade. I guess I was looking for confirmation that these were bugs, and not just a bad build or something or intentional design change, then I'd open tickets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've found out why it was confusing --tab and --tab-name and fixed it. I think you're right, the separate windows, ignoring --tab, is probably a separate issue, a race condition between tab2's instance and tab1's dbus. I can reproduce the problem with a simple script and --fork does fix it for me.
(You may have seen an earlier version of this message saying --fork doesn't fix it, that was because I actually forgot to use --tab in my script, duh!)
Last edit: Tony Houghton 2013-03-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
of course --window== would be optional, if you only have one window or don't care which gets the new tab,
It would seem like --separate adds yet another complication. --replace implies there can only be one Roxterm instance operating as a Dbus service. Does that mean if you use --separate, only one instance will be controllable via Dbus?
-Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like returning from the dbus functions doesn't necessarily guarantee that the service is up and running :-(. I don't know what I can do about that then. One day I might do a rewrite and replace dbus with GtkApplication and gsettings. It will be interesting to see what happens then. In the meantime I don't want to get too involved with dbus issues.
If there is more than one roxterm window open, first it will see if one already has focus and use that if so. Otherwise it just uses the first in its list. But I changed it a few versions back so that it won't reuse windows from a different workspace (ie not the one that a new window would be opened in if --tab wasn't used IYSWIM). You can use --tab in conjunction with -T/--title to reuse a window with a given title.
The difference between --separate and --replace is that --replace makes the new instance take over the dbus service - and if the second instance is closed dbus automatically hands ownership of the service back to the previous instance AFAICT. With --separate the new instance doesn't replace any other as the dbus service.
Last edit: Tony Houghton 2013-04-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like returning from the dbus functions doesn't necessarily guarantee that the service is up and running :-(. I don't know what I can do about that then.
Can you clarify how --fork works?
Something like:
Roxterm starts, sees --fork option, forks and launches a roxterm child instance. Then the first (parent) instance sends a Dbus command to the child instance, and waits for a reply. When received, it exits, leaving only the child instance running.
If that's correct, then presumably the Dbus command sent to the child ultimately invokes some code in the child, right? Can the child not determine if it is in a "up and running" state?
Are you saying the Dbus subsystem is returning a reply to your Dbus call without actually invoking code in the child?
Maybe there is a flaw in the --tab code that determines whether to talk to an existing instance or spawn a new one? (By implication, its apparently doing something different than what --fork uses to determine when to return.)
Last edit: Tom Metro 2013-04-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Roxterm starts, sees --fork option, forks and launches a roxterm child instance. Then the first (parent) instance sends a Dbus command to the child instance, and waits for a reply. When received, it exits, leaving only the child instance running.
Not quite. The parent waits for the child to send "OK" down a pipe, which it does after it's initialised its dbus service. The trouble with sending a dbus command is I don't really know what happens if you send a command between trying to start the service and the service actually becoming globally available. The current behaviour with --fork not working implies to me that dbus doesn't handle race conditions when starting services too well. Roxterm doesn't install a .service file, but if it did and there is no race prevention, calling a command before the service has started properly could also result in more instances being started.
Maybe I need to research this more rather than waiting until I rewrite without dbus which could be a long time in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The parent waits for the child to send "OK" down a pipe...
Literally? A named pipe?
So you're avoiding using Dbus because of your concern for a race condition with launching a listener service (under certain circumstances)?
So one possibility is the point at which you are saying "OK" is too soon in the process. Maybe it is as simple as reordering the code. Is setting up a Dbus listener asynchronous?
Another possibility: maybe there is a Dbus API call the child can use to test the readiness of its own listener, without triggering an endless loop of spawning listeners? The the child only responds OK when it knows it is ready.
Seems I could hack my startup script to loop over that with 1 second sleeps, rather than pausing for 20 seconds. But obviously having Roxterm handle this internally is ideal.
A successful poll could be followed by an "are_you_ok()" Dbus method call, with an "OK" reply, just to confirm there really is a working listener.
(Although what happens if you combine --fork and --separate? Could be misleading results, as the parent will be talking to some other instance acting as the Dbus listener. Maybe you are best sticking with your current pipe technique, and have the child poll for the Dbus readiness if and only if it is asked to be a Dbus listener.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The parent waits for the child to send "OK" down a pipe...
Literally? A named pipe?
Not a named pipe, but the anonymous sort created by pipe(). And I was wrong about "OK", it actually sends a 0 or 1 "raw" byte depending on whether there was an error.
So you're avoiding using Dbus because of your concern for a race condition with launching a listener service (under certain circumstances)?
It was mainly because I thought the best way to test whether the service was ready was getting a successful return code from the function that started it, and that function is called in a separate process from the one that needs to wait.
So one possibility is the point at which you are saying "OK" is too soon in the process. Maybe it is as simple as reordering the code. Is setting up a Dbus listener asynchronous?
The child doesn't send the OK code until it's called all the dbus functions to set up the service, so it appears the latter is asynchronous.
Another possibility: maybe there is a Dbus API call the child can use to test the readiness of its own listener, without triggering an endless loop of spawning listeners? The the child only responds OK when it knows it is ready.
That's what I'm hoping for. Whether there is such a call or I just poll the service, that could be done from the parent process, making the pipe unnecessary. But in the latter case at least, I'd have to make a special call that does something like return the pid of the owning process, so the caller would know whether --replace has worked.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If there is more than one roxterm window open, first it will see if one already has focus and use that if so. Otherwise it just uses the first in its list. But I changed it a few versions back so that it won't reuse windows from a different workspace...
Ah, clever. So that probably addresses the need for most use cases.
(ie not the one that a new window would be opened in if --window wasn't used IYSWIM).
Is --window an existing switch? (Not shown by "roxterm --help". GTK+ option? I don't see it in --help-gtk either.)
You can use --tab in conjunction with -T/--title to reuse a window with a given title.
I see. So that addresses the more complicated use case where you want to open multiple windows on the current workspace and then specify which gets a new tab.
(I see you have this documented under --tab in the man page. I agree it is probably too much detail for the --help screen.)
So what happens if your window title is set to '%s'? Does:
roxterm --title %s --tab ...
work as expected? (I'm assuming it tests against the literal before the substitution occurs.) This might be worth documenting.
(Presumably if you wanted to manage multiple windows, you'd have to set --title to something other than %s on the other windows.)
On a side note, I noticed in the man page:
--fullscreen -f
Make initial terminal window take up the whole screen with no window furniture.
Window furniture? Isn't the term window decoration?
Last edit: Tom Metro 2013-04-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So what happens if your window title is set to '%s'? Does:
roxterm --title %s --tab ...
work as expected? (I'm assuming it tests against the literal before the substitution occurs.) This might be worth documenting.
(Presumably if you wanted to manage multiple windows, you'd have to set --title to something other than %s on the other windows.)
I had to check the code for that one, but I see it uses the "title template" which means without expanding %s. That is more consistent with the standalone use of --title, but I wonder whether it would make more sense to match the expanded version instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder whether it would make more sense to match the expanded version instead.
Wouldn't that make it hard to predict? If you are using %s, the window title will change every time the focused tab switches. That doesn't strike me as friendly for automation.
If your concern is what happens when the user wants to use '%s' on multiple windows, and still address them independently, then adding a fixed prefix might be the workaround.
This is the price you pay for overloading functionality. :-) The more programmerish solution is the one I suggested, which is having --fork return some sort of ID, but that approach is less friendly, and not all use cases will involve use of --fork.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The difference between --separate and --replace is that --replace makes the new instance take over the dbus service...
So they both spawn a new instance? That isn't clear from the documentation, but if you think about it, I guess that's implied.
It would seem more natural to have --replace be a modifier that can only be used with --separate. I guess the way you have it makes for a shorter command line, if that matters.
What's the use case for --separate? Have you had much demand for it?
With --separate the new instance doesn't replace any other as the dbus service.
So then that new instance is inaccessible from Dbus, right?
(My knowledge of Dbus doesn't go that deep, but my recollection is that you locate an instance using a fixed string identifier, and I'm guessing there can only be one service answering for that identifier.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The difference between --separate and --replace is that --replace makes the new instance take over the dbus service...
So they both spawn a new instance? That isn't clear from the documentation, but if you think about it, I guess that's implied.
Yes.
It would seem more natural to have --replace be a modifier that can only be used with --separate. I guess the way you have it makes for a shorter command line, if that matters.
--replace is used by some other applications which provide a service, eg window managers, so making roxterm need another option in conjunction would make it less consistent with them. I also prefer to make options imply each other than give an error if one is used without the other.
What's the use case for --separate? Have you had much demand for it?
I suppose not. I use it myself when I want to test something unrelated to dbus in a newly compiled version without having to close the terminal I'm working in and use gnome-terminal instead. --replace could potentially be more disruptive then.
With --separate the new instance doesn't replace any other as the dbus service.
So then that new instance is inaccessible from Dbus, right?
(My knowledge of Dbus doesn't go that deep, but my recollection is that you locate an instance using a fixed string identifier, and I'm guessing there can only be one service answering for that identifier.)
I think that's right. It would also mean any version not providing the dbus service wouldn't respond to profile changes etc, which is another good reason to switch to gsettings. I avoided using gconf originally because it's not all that great at handling an indefinite number of profiles, but my thought that people might exchange config files didn't really come to anything, except one occasion when somebody donated the Tango colour scheme.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I upgraded to 2.6.4-1ppa1precise1 (as the version implies, from the Ubuntu PPA) recently from whatever is the version in the 12.04 official repositories, and on restart with my usual startup script noticed the following:
-All tabs were opened as separate windows. The core of the script looks like:
roxterm --tab-name tab1 &
sleep 2
roxterm --tab --tab-name tab2
roxterm --tab --tab-name tab3
[...]
In the past, this has worked as expected. The 2 second sleep is adequate for the roxterm process to start, and subsequent invocations with --tab open new tabs in the original window.
I closed all the windows except for the first one created and ran my startup script from that and it created the tabs as expected in that window.
Do I need a longer delay with this version for some reason? Is there a deterministic way of doing this? (I'm sure I could hack something together with xdotool, but how about a command line option?)
-the --tab-name option appears to be broken. All of my tabs are named the same as my window, which is the title passed to the first instance.
I thought maybe the command line syntax changed, but --help documents the same API, and no errors were reported to the console when I ran my script to launch Roxterm. Bug?
-all tabs have a number prefix on the title:
Is there an option to disable that? (I haven't gone huinting through the GUI yet.)
-Tom
Last edit: Tom Metro 2013-03-13
Hm, for some reason I didn't get round to releasing 2.6.5 or 2.6.6 in my
PPA. A new "upstream" version is long overdue anyway. But I don't think 2.6.6 would fix this for you anyway, I'm also experiencing some odd behaviour with the --tab and --tab-name options. --tab on its own seems OK, but --tab-name seems to behave like --tab, whereas -n works correctly. If you replace your --tab-name options with -n does that fix it for you?
The tab number prefix is an option, it's in the Tabs section of the profile, near the top-right of the dialog.
I've been waiting months for this reply...assumed you were just busy. Turns out Sourceforge apparently was dropping emails. No Roxterm forum emails sent betweeen my last tmux posting on 12/14 and a message from Jim Paris on 1/11. Weird. [Looks like I wasn't subscribed to Help.]
Good that it is reproducible.
Yes.
Ah, I see. Any idea why that would have gotten enabled? It wasn't set by me.
I originally wrote:
I ended up boosting the 2 second delay to 20 seconds, and that relibly resolved the problem.
I saw you menion --fork in abother thread. That sounds like exactly what I want if it only returns control after the first instance is prepared to receive D-BUS messages.
Last edit: Tom Metro 2013-03-13
I overlooked this as one of the things that should be fixed before releasing 2.7, so it's a good job I hadn't quite got round to the release yet. Please could you use the ticket system in future, because it makes it easier to keep track of bugs.
I think you have two symptoms and two or three solutions:
Problem 1. Tabs opening in separate windows despite --tab.
Problem 2. Incorrect tab names (--tab-name being overlooked).
Solution 1. Increase the sleep delay.
Solution 2. Use --fork.
Solution 3. Use -n instead of --tab-name.
Do all three solutions (on their own, not used together) fix both problems or just one or the other?
I made the tab numbering option on by default. I sometimes do that with new options eg if I think more people will like it than not. Having the numbers visible is a handy cue for fast switching with Alt+<n>. I thought there were mnemonics in the menu items for that, but apparently not. I also seem to have just discovered a bug in GTK3 wrt showing mnemonics when you press Alt https://bugzilla.gnome.org/show_bug.cgi?id=695775.
Last edit: Tony Houghton 2013-03-13
Correct.
Tested and confirmed to work.
I've updated my script to use this instead of a delay. I can't effectively test it without shutting down my current Roxterm instance, which is disruptive. (I tried opening a new window, and then launching the script from there, which opened a 3rd window, and created some sort of an endless loop with the subsequent programs Roxterm launches per my command lines. I don't get why there would be a loop, but I killed off all the new instances. So I can't confirm it works just yet.)
I'll post a follow-up after I've been able to test it.
Correct. Apparently unrelated to Problem 1.
Tested and confirmed to work. I've updated my script to use -n.
Problem 3. was the tab numbering, which was resolved by altering the setting.
No, but any expectation that they should? For example, increasing the delay didn't fix the labeling of tabs.
Ah...
Sure. A feature I don't use. The change probably would have been less jarring had the tab labels been as expected. Though I still would have turned it off. The numbers take up space and serve no purpose for me.
Maybe add an option to the tab context menu to enable/disable the numbering? Or is that abusing the menu with settings that are rarely changed?
When I press Alt, the underlined letters appear on the menu bar items, yet when a popup menu is displayed, pressing Alt does nothing. That? (Same behavior in other GTK apps I'm running. Firefox shows underlines always.)
Absolutely. I actually hate reporting bugs via forums. Way too difficult to tell if the same issue has already been repprted.
I chose the forum option here because I was seeing a bunch of issues simultaneously after a version upgrade. I guess I was looking for confirmation that these were bugs, and not just a bad build or something or intentional design change, then I'd open tickets.
I've found out why it was confusing --tab and --tab-name and fixed it. I think you're right, the separate windows, ignoring --tab, is probably a separate issue, a race condition between tab2's instance and tab1's dbus. I can reproduce the problem with a simple script and --fork does fix it for me.
(You may have seen an earlier version of this message saying --fork doesn't fix it, that was because I actually forgot to use --tab in my script, duh!)
Last edit: Tony Houghton 2013-03-18
A system reboot gave me an opportunity to test this with 2.7.1-1ppa1, and a script like:
resulted in a collection of separate wndows.
(Tabs names worked correctly this time, since switching to -n.)
I closed all the windows, uncommented my sleep line after the first roxterm command and tried again, and it worked.
So in my testing --fork doesn't work, unless you fixed it in a newer version.
On a related note, it seems like a piece is missing here. What happens if I have multiple Roxterm wndows? How does:
know which window to use?
Seems like it should be something like:
of course --window== would be optional, if you only have one window or don't care which gets the new tab,
It would seem like --separate adds yet another complication. --replace implies there can only be one Roxterm instance operating as a Dbus service. Does that mean if you use --separate, only one instance will be controllable via Dbus?
-Tom
Looks like returning from the dbus functions doesn't necessarily guarantee that the service is up and running :-(. I don't know what I can do about that then. One day I might do a rewrite and replace dbus with GtkApplication and gsettings. It will be interesting to see what happens then. In the meantime I don't want to get too involved with dbus issues.
If there is more than one roxterm window open, first it will see if one already has focus and use that if so. Otherwise it just uses the first in its list. But I changed it a few versions back so that it won't reuse windows from a different workspace (ie not the one that a new window would be opened in if --tab wasn't used IYSWIM). You can use --tab in conjunction with -T/--title to reuse a window with a given title.
The difference between --separate and --replace is that --replace makes the new instance take over the dbus service - and if the second instance is closed dbus automatically hands ownership of the service back to the previous instance AFAICT. With --separate the new instance doesn't replace any other as the dbus service.
Last edit: Tony Houghton 2013-04-14
Can you clarify how --fork works?
Something like:
Roxterm starts, sees --fork option, forks and launches a roxterm child instance. Then the first (parent) instance sends a Dbus command to the child instance, and waits for a reply. When received, it exits, leaving only the child instance running.
If that's correct, then presumably the Dbus command sent to the child ultimately invokes some code in the child, right? Can the child not determine if it is in a "up and running" state?
Are you saying the Dbus subsystem is returning a reply to your Dbus call without actually invoking code in the child?
Maybe there is a flaw in the --tab code that determines whether to talk to an existing instance or spawn a new one? (By implication, its apparently doing something different than what --fork uses to determine when to return.)
Last edit: Tom Metro 2013-04-14
Not quite. The parent waits for the child to send "OK" down a pipe, which it does after it's initialised its dbus service. The trouble with sending a dbus command is I don't really know what happens if you send a command between trying to start the service and the service actually becoming globally available. The current behaviour with --fork not working implies to me that dbus doesn't handle race conditions when starting services too well. Roxterm doesn't install a .service file, but if it did and there is no race prevention, calling a command before the service has started properly could also result in more instances being started.
Maybe I need to research this more rather than waiting until I rewrite without dbus which could be a long time in the future.
Literally? A named pipe?
So you're avoiding using Dbus because of your concern for a race condition with launching a listener service (under certain circumstances)?
So one possibility is the point at which you are saying "OK" is too soon in the process. Maybe it is as simple as reordering the code. Is setting up a Dbus listener asynchronous?
Another possibility: maybe there is a Dbus API call the child can use to test the readiness of its own listener, without triggering an endless loop of spawning listeners? The the child only responds OK when it knows it is ready.
Or how about this...have the parent poll for the service. Here's code that shows how to enumerate the available services:
http://stackoverflow.com/questions/9792258/dbus-how-can-i-list-all-services-bus-name-in-the-system-bus
And via command line:
Seems I could hack my startup script to loop over that with 1 second sleeps, rather than pausing for 20 seconds. But obviously having Roxterm handle this internally is ideal.
A successful poll could be followed by an "are_you_ok()" Dbus method call, with an "OK" reply, just to confirm there really is a working listener.
(Although what happens if you combine --fork and --separate? Could be misleading results, as the parent will be talking to some other instance acting as the Dbus listener. Maybe you are best sticking with your current pipe technique, and have the child poll for the Dbus readiness if and only if it is asked to be a Dbus listener.)
Not a named pipe, but the anonymous sort created by pipe(). And I was wrong about "OK", it actually sends a 0 or 1 "raw" byte depending on whether there was an error.
It was mainly because I thought the best way to test whether the service was ready was getting a successful return code from the function that started it, and that function is called in a separate process from the one that needs to wait.
The child doesn't send the OK code until it's called all the dbus functions to set up the service, so it appears the latter is asynchronous.
That's what I'm hoping for. Whether there is such a call or I just poll the service, that could be done from the parent process, making the pipe unnecessary. But in the latter case at least, I'd have to make a special call that does something like return the pid of the owning process, so the caller would know whether --replace has worked.
Ah, clever. So that probably addresses the need for most use cases.
Is --window an existing switch? (Not shown by "roxterm --help". GTK+ option? I don't see it in --help-gtk either.)
I see. So that addresses the more complicated use case where you want to open multiple windows on the current workspace and then specify which gets a new tab.
(I see you have this documented under --tab in the man page. I agree it is probably too much detail for the --help screen.)
So what happens if your window title is set to '%s'? Does:
work as expected? (I'm assuming it tests against the literal before the substitution occurs.) This might be worth documenting.
(Presumably if you wanted to manage multiple windows, you'd have to set --title to something other than %s on the other windows.)
On a side note, I noticed in the man page:
Window furniture? Isn't the term window decoration?
Last edit: Tom Metro 2013-04-14
work as expected? (I'm assuming it tests against the literal before the substitution occurs.) This might be worth documenting.
(Presumably if you wanted to manage multiple windows, you'd have to set --title to something other than %s on the other windows.)
I had to check the code for that one, but I see it uses the "title template" which means without expanding %s. That is more consistent with the standalone use of --title, but I wonder whether it would make more sense to match the expanded version instead.
Wouldn't that make it hard to predict? If you are using %s, the window title will change every time the focused tab switches. That doesn't strike me as friendly for automation.
If your concern is what happens when the user wants to use '%s' on multiple windows, and still address them independently, then adding a fixed prefix might be the workaround.
This is the price you pay for overloading functionality. :-) The more programmerish solution is the one I suggested, which is having --fork return some sort of ID, but that approach is less friendly, and not all use cases will involve use of --fork.
Sorry, I meant --tab. I'll edit my previous post to avoid confusing others in the future.
I suppose so. I think Acorn used to call it furniture and I kept the habit from my RISC OS days.
So they both spawn a new instance? That isn't clear from the documentation, but if you think about it, I guess that's implied.
It would seem more natural to have --replace be a modifier that can only be used with --separate. I guess the way you have it makes for a shorter command line, if that matters.
What's the use case for --separate? Have you had much demand for it?
So then that new instance is inaccessible from Dbus, right?
(My knowledge of Dbus doesn't go that deep, but my recollection is that you locate an instance using a fixed string identifier, and I'm guessing there can only be one service answering for that identifier.)
Yes.
--replace is used by some other applications which provide a service, eg window managers, so making roxterm need another option in conjunction would make it less consistent with them. I also prefer to make options imply each other than give an error if one is used without the other.
I suppose not. I use it myself when I want to test something unrelated to dbus in a newly compiled version without having to close the terminal I'm working in and use gnome-terminal instead. --replace could potentially be more disruptive then.
I think that's right. It would also mean any version not providing the dbus service wouldn't respond to profile changes etc, which is another good reason to switch to gsettings. I avoided using gconf originally because it's not all that great at handling an indefinite number of profiles, but my thought that people might exchange config files didn't really come to anything, except one occasion when somebody donated the Tango colour scheme.