GNOME Bugzilla – Bug 585841
Need vte_terminal_fork_command variant that return a GError
Last modified: 2010-03-17 18:31:47 UTC
For g-t, I need a way to get a GError back when fork_command fails, so I can display a meaningful message to the user instead of the useless "There was an error creating the child process for this terminal". Attached patch provides this; it also adds extra child setup (bug 514447). It will also make implementing bug 320128 easier. The 2 different flags arguments aren't ideal; I tought about extending GSpawnFlags (taking the highest bits for our flags), but that probably wouldn't work well for the generated enum types nor for the bindings / introspection. Behdad: could you take a look to see if this patch is sane?
Created attachment 136625 [details] [review] proposed patch Another question I have is why fork_command always uses G_SPAWN_CHILD_INHERITS_STDIN; is that necessary for something in our impl? vteapp seems to work without it...
If there are no comments, I'm going to commit this patch this week.
Created attachment 149109 [details] [review] current patch
Looks good. The spawn() docs can use another review. Feel free to commit (though, I appreciate if you wait till next week).
Actually I'm working on yet another different API, so I'll hold off on committing this.
Created attachment 149863 [details] [review] different API
Created attachment 152228 [details] [review] updated patch
Didn't really do a review, but any reason why some functions have two leading underscores? I think at this point, you should commit this if you are confident in it, and make any further changes later. Unless you'd rather postpone this to next cycle. API freeze was, like, yesterday?
Most of the __vte_pty_* functions are named this way to avoid exporting them, since the _vte_pty_* functions are explicitly exported from libvte. API freeze only applies to platform libs, which vte is not. However this is a rather big change, so I think I'll put it on a branch first and merge it after vte branches for 2.30.
Sounds good.
Also, should we simply stop exporting _vte_pty_* for next version?
I'd say that's something for vte 1.0 .
Pushed to the "new-pty" branch.
Pushed to master.