Re: Unique BonoboControl

A Ter, 2003-11-04 às 13:40, Mikoyan escreveu:
> On Tue, 2003-11-04 at 14:44, Michael Meeks wrote:
> > Hi Mikoyan,
> 
> Hi
> [...]
> > 
> > 	Ok - you sure associating all this with a 'Control' is what you really
> > want to do ? a Control in Bonobo land is a very specific thing - a
> > single view, graphical item. This contrasts with Windows where the word
> > 'Control' is meaningless [ an invisible timer 'control' eg. ;-]
> 
> I've no specific windows programming experience. The only controls
> I know are BonoboControls :-)
> 
> > > So the question is simple: what should I do?
> > 
> > 	Explain what you are trying to achieve; is it that you want to have
> > only 1 running instance of your app, and to pass cmdline arguments to
> > the running instance when new versions are run ?
> 
> No. I have an object running that outputs results to a GUI. This "GUI"
> is a BonoboControl. If someone/something already activated this control,
> the object just retreives a ref to this control and start sending its
> output to it. But if the object discovers that the control was not
> yet running, it will create the bonobocontrol (trough a normal factory
> i guess) and put it in its own brand new bonobowindow. (after which it
> will send its output to the control).
> 
> I don't know another way to explain what I'm trying to achieve :-)

  I think that what you mean by "control" is actually a simple
application that can have a single instance running.  Some examples of
other applications implementing the same thing are: rhythmbox,
gnome-terminal, galeon. 

 This is sometimes called "Automation", because it allows a script to
control, through CORBA, a running application, like what is sometimes
achieved with a command-line interface (like the mailto: URI handler
command: evolution "%s").  Of course, CORBA is much more comfortable for
automation than CLI, especially through a scripting language like Python
or Perl. ;)

  The effect is achieved in gnome-terminal by (see
gnome-terminal/src/terminal.c):
	1. A .server file for the application is installed, indicating that the
server implements Bonobo::EventSource;
	2. On application startup, a BonoboEventSource is created;
	3. then, the server object is registered using
bonobo_activation_active_server_register;
	4. if registration fails, it (usually) means that another application
instance is already running:
		4a. get reference to running server
		4b. send argc/argv to the running server
		4c. exit process
	5. process argc/argv

  And yes, the Bonobo Unique Application (GEP 12) intends to solve this
specific use case elegantly.

  Regards.

-- 
Gustavo João Alves Marques Carneiro
<[email protected]> <[email protected]>