You have to use --disable-factory to use command line args at the
moment, because forwarding args from command line to the factory is
not implemented.

Attached is a patch that implementes argument passing to the factory.
I'm not sure if it's the "right" way of doing it, but it works for me
... the arguments all get passed.

Except I can't get the popt context to actually run over them and
parse them.  Maybe somebody else can check that out ... look at the
terminal_new_event function.

I've also moved the stuff from 'main' that creates a new terminal from
the OptionParsingResults into a function
terminal_app_terminal_new_from_results so the code can be reused in
the terminal_new_event function.

Created attachment 8331 [details] [review]
patch to pass arguments to factory

> Except I can't get the popt context to actually run over them and
> parse them.  Maybe somebody else can check that out ... look at the
> terminal_new_event function.

Yes, that's the problem. ;-) Michael already wrote the code to forward
the args to the factory. But actually parsing is hard, especially once
you realize you need to handle the args provided by gtk and libgnome(ui).

I think I would rather serialize the OptionParsingResults into
something simple-to-parse and pass that to the factory, instead of
passing the raw args. Was planning to put something together this weekend.

Well, the way it is right now _is_ simple to parse -- if popt was
working. I don't understand why poptGetContext just doesn't do
anything right now. Otherwise this would work fine.

I don't really understand the whole factory concept. But, I thought we
would just ignore GTK/Gnome options when we spawn a window from the
factory. Since really the window is just part of the already running
factory. So the GTK/Gnome options only make sense when starting the
factory in the first place (since that is the real app).

So with my code right now, if popt was working, everything would be
fine and we would just discard GTK/Gnome options when spawning a new
window from the factory.

If you got popt working you could save yourself some time by not
having to do any additional coding!

poptGetContext() doesn't parse the args, you have to do a loop
as in gnome_program_parse_args() in order to parse. poptGetContext() 
just prepares to parse. 

However, the reason you can't just parse things in the "options" table
is that you'll get a syntax error on the options that libgnome and gtk
and so on normally handle. So those options at least have to be
stripped out. Also, some of them _do_ apply, at least in a multihead
world for example we want to use --display.

I think it's cleaner to push the parse results over the wire instead
of the actual command line args, but it's also kind of lame in some
ways (it's more code, and the launcher terminal will connect to the
display even though it doesn't intend to open any windows...)

I see, I thought poptGetContext did all the parsing and also called
the callback. Anyway, I don't really understand popt.

But this whole factory concept seems like a lot of hassle. Why did you
make it a factory? Wouldn't it have been easier to make the terminal
widget into a bonobo control so that the gnome-terminal program is
just a shell for it? Then every program instance would be seperate and
you could also use the bonobo terminal for other things, like a
nautilus view for example. Or is that also possible with the factory?

I'm not trying to critisize your work here, I'm just asking (as a
student) why some things are the way they are.

The factory concept was also used in gnome 1. It has two purposes; 1)
to save memory overhead and 2) to start new terminal windows faster,
both benefits are gained by having a single terminal process.

I don't think a bonobo control has any benefit over plain libzvt, as
far as using the terminal in a nautilus view or whatever.

*** This bug has been marked as a duplicate of 71442 ***

Hmm ... I wonder if the performane increase is really worth the added
complexity of having a factory.

I was thinking it might be an advantage to wrap up the terminal in a
bonobo control since the control would then also load all the prefs
saved by profterm. Then if you embed a terminal in nautilus (or
anywhere else for that matter) it will keep the same preferences you
are used to (such as font size, colors, etc). The control could also
implement the same right-click menu as profterm - that would make the
UI seem very consistent. profterm itself would then just be a shell
for the bonobo control with some additional features like tabs.

That might be cool for post 2.0 ....