Created attachment 15161 [details] [review]
This adds geometry & active tab to session

The patch adds geometry to the RestartCommand in the session,
and four new cmdline options:

--window: like --window-with-profile but using the default profile

--tab: like --tab-with-profile but using the default profile

--repeat: repeats the last tab COUNT times, so u can say 

   gnome-terminal --repeat 3

and you get 4 tabs (the "extra" tab can be avoided,  but that would
change the behaviour of the existing cmdline options...)

--active: makes the last specified tab the active one.

The first three are just convenient (I think there should be --profile
and --profile-internal-id options, and --tab-with-profile, etc, should
be dropped, because that would make options a bit more orthogonal),
and the --active one is needed to store active tabs in the session.

Cheers,

-- m

Saving --geometry is wrong, that is the window manager's
responsibility according to the specifications. 

I like --active and saving --active in the session, would like to see
that part of the patch split out.

--window/--tab/--repeat seem like they're adding extra options that
aren't needed. They may have been a better way to do it from scratch, 
but deprecating --window-with-profile isn't very easy (it breaks lots 
of existing sessions and desktop files), and so we would just have 
the duplication forever. What is wrong with "--window-with-profile
default" other than extra typing?

Funny, I have just read you yourself comment that "metacity _can't_ do
it, there isn't enough information available." in 84984 ;)

I think I'm running the latest metacity (2.4.34) and it does not save
geometry, at least not for gnome-terminals... Maybe that is a metacity
bug, granted, but I could refer you to 84984.

I'll post the --active patch, if you want it.

Apart from extra typing (never to be overlooked) it's a bit annoying
to have to know how the default profile is called (it's not
necessarily Default...), and having to specify it anyway defeats the
whole concept of defaultness, at least from the command line point of
view.

I don't feel that strongly about --repeat, though "gnome-terminal
--repeat 4" is a lot less typing than "gnome-terminal
--tab-with-profile=Default --tab-with-profile=Default
--tab-with-profile=Default --tab-with-profile=Default," isn't it?

This is not abstract: I do start gnome-terminals from the command line
 quite frequently, and up to now now the command-line rewriting was
being done by a script.

One thing I would love, and which is not difficult though I cannot
think of what the UI should be like, is a save-state-to-a-launcher,
pretty much like the save-state-to-session, but which sets up
something one can put on the desktop for you to click on.

Btw, how does one (if possible) specify a geometry for a window which
includes the workspace?

84984 is about saving within a session, while this patch is about 
saving across sessions. There is a spec for saving across. 
Saving within is harder but there's a metacity patch for it
still in the works.

If saving across sessions doesn't work, then it is a metacity bug
probably. See ~/.metacity/sessions (and ignore the way gnome-session
fails to run DiscardCommand to clean up those files...) and 
metacity/src/session.c

I guess --tab/--window aren't so bad. --repeat I'm still having
trouble talking myself into. ;-)

Workspace could be implemented as --workspace, but perhaps this 
isn't much of an issue if we get window history in metacity, and 
with startup notification (terminals should always come up on the 
workspace where you clicked the launcher, if your launcher 
has StartupNotify=true - in GNOME 2.2 the launcher should have that).
So I'd like to hold off on --workspace until we have window history in
metacity and see if it's still an issue.

After rm'ing everything in .metacity/sessions it turns out that my
gnome-terminals do get positioned correctly (I had a couple of files
in there which were just an empty <metacity_session/> element; maybe
my .gnome2/session was pointing to one of them? I don't know since the
idea  came to me after deleting them...)

But window sizes do not get restored: gnome-terminals restarted with
the session all turn out in classic 80x24 size. After a lot of log
in/log out cycles, I discovered that the window is being initially
presented with the correct (ie, as saved in the session) size, and
then reset to 80x24, only this happens so fast I had not even noticed. 

The problem is neither gnome-terminal nor metacity, but vte. It turns
out that $GNOME_HOME/share/vte/termcaps/xterm (its default termcap)
includes the fields co#80 and li#24, so what's happening is that in
the absence of a --geometry spec in the RestartCommand, the
gnome-terminal window is created with the
.metacity/sessions/whatever.ms stored size, but immediately afterwards
it is resized into 80x24.

It's not vte's fault, though, since it is right in using the termcap
entry: gnome-terminal never calls vte_terminal_set_size upon
initialization from cmdline *unless* there is an explicit --geometry.

The only way out I see is having g-t store the window size actually
allocated to it by the wm when it presents the window, and then
calling vte_terminal_size appropiately.

Created attachment 15178 [details] [review]
Patch to add --active

Created attachment 15179 [details] [review]
Patch to add --tab and --window

Ok, those were orthogonal patches. --repeat is not included.

There is a little piece of ugliness IMO in that saying

  gnome-terminal --tab --tab --window --tab --tab

is not the same as doing

  gnome-terminal --tab --tab

twice. Indeed, in the first case, the window produced by --window has
*three* tabs. This behaviour is has nothing to do with the patches, as
it depends only on the logic already used in --tab-with-profile &c.

Btw, a bit off topic, but: (1) it'd be very useful if the case in the
parse_option_callback dealing with OPTION_COMPAT would include the
deprecated option longName in the message, and (2) unrecognized
options are ignored (after the paranoid OPTION_LAST case in
parse_option_callcack, there is a comment I don't understand which is
relevant to this?)
  

The --active patch is good to commit, all I noticed are three 
cases that need a space before parens ("active (" vs. "active(")

In the --tab/--window patch, the documentation for these
options still mentions the profile name; that isn't correct 
is it?

The code: "profile ? g_strdup (profile) : NULL" is not needed, 
as g_strdup() allows a NULL argument and just returns NULL then.
Similarly, in "if (it->profile) g_free (it->profile)" NULL 
is an acceptable argument to g_free().

--tab/--window patch looks good other than those items.

Re: off-topic items, having OPTION_COMPAT report the name 
of the option would indeed be good, I don't remember why 
I didn't do that. The comment about OPTION_LAST is that 
if you extend the OPTION_* enum the compiler will warn about 
how the switch statement doesn't handle new values.

If you patch the OPTION_COMPAT issue please open a new report, 
it's best to keep one issue per bug report or it gets 
kind of confusing.

Thanks a lot for the patches!

Next is the patch with the --window doc fixed and your comments about
the code. About spacing: yeah, I tried to keep general style, but I'm
more of a -npcs -sa{f,i,w} indenting kind of person; I'll try harder :)

Created attachment 15203 [details] [review]
Fixed patch to add --tab and --window

Patch applied in CVS, thanks. Will be in gnome-terminal 2.3.x/2.4.x

OK, so what is the deal here?  My terminal still starts in 80x24 and the same
position of the screen every time.  Why is this marked resolved?  If it is a
metacity or vte problem, should there not be a comment:

This bug is a duplicate of metacity|vte bug #xxxxx (url) ?

What version of g-t are you using? Are you saving the session when you log out?