Re: Unique BonoboControl

On Tue, 2003-11-04 at 14:59, Gustavo J. A. M. Carneiro wrote:
> 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. 

Well, I really meant a Control. Hmmmz, ok, I'm not sure if this is want
i really want in the end, but in the meantime I've learned :-)

Just imagine an object that outputs its data to a simple control. If
another app has already activated such control (ie. embedded in its
own), it just uses the already running activated control. If not , it 
just creates its own window with control to sends its output to.
(don't ask my why i think this is usefull :-))

But ...

>  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. ;)

(Interesting ... more apps should have this. Is someone pushing python+
corba as the scripting heaven for gnome? Btw, when is gnome-python with
this fix comming [http://bugzilla.gnome.org/show_bug.cgi?id=107658];-))

>   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

The code was indeed usefull. I've something now that really works as I
want it. Although, first creating a control, trying to register it, and
if it fails destroying that control and getting a ref of the already
running control is not what i call beautiful :-) But it looks cool
though :-)

For what is bonobo_activation_active_server_register normally used?
(in the docs there is bonobo_activation_register_active_server, which
has also another signature...)

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

Nice

>   Regards.

Many thanks to both of you.

Steven