Re: Unique BonoboControl
- From: Mikoyan <miko2 pandora be>
- To: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Cc: Michael Meeks <michael ximian com>, bonobo <gnome-components-list gnome org>
- Subject: Re: Unique BonoboControl
- Date: Wed, 05 Nov 2003 20:20:20 +0100
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 :-))
> 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
> 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
> 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
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.
Many thanks to both of you.
] [Thread Prev