Re: Control center and conduits

[Manish Vachharajani <mvachhar vger rutgers edu>]

On Fri, 18 Sep 1998, Michael Fulbright wrote:

> 
> mvachhar@vger.rutgers.edu said:
> > Hmm, well is there any way to get a control center applet to also run
> > stand alone by doing any tricks?
> 
> As I understand it, we write a .desktop file for each capplet. This
> has a command line to execute the capplet - so we could run
> 
> memo-conduit-properties --capplet
> 
> to make it act like a capplet. W/o the --capplet, it would be a normal
> GTK/GNOME program.
> 
> I'm not sure I understand why we wouldn't just make them capplets tho -
> we pretty much are assuming people have GNOME installed if they
> run the properties program, don't we?

Well, we don't make them capplets because the current pilot config stuff
doesn't handle multiple pilots.  The properties programs need to handle
multiple pilots.  I don't know if they currently do or not, but they
should.  We can use the command line as a way to launch the properties
programs in capplet mode, but how would the admin tool call them then when
dealing with multiple pilots?  Or will we make the control center stuff
support multiple pilots per user?  And if we do support multiple pilots
per user in the capplet how do we populate the tree on the left
dynamically without .desktop Files?  Can a capplet control its subtree?
 
> As far as implementing widgets that present the same attrbiute in
> multiple capplets (like default sync method), I think the code to
> create these widgets is simple enough we won't lose too much if people just
> copy the code around.  If there are most compilcated widget configurations
> that multiple capplets will share, we may need a library to properly
> share the code.

As long as the look and feel remain the same I don't care.  I thought the
best way to ensure the same look and feel for the same functionality was
to have a default widget.  This widget would have to be able to read the
conduit .so file, or otherwise be told which of the sync methods the
conduit supports though.  I am not sure that copying code is the best
thing to do if we add common, per conduit config options though.  Maybe we
should have a library.

> I'm not exactly sure why gpilotd is worried about how to invoke the
> conduit configure program - could you explain this?

gpilotd doesn't and shouldn't care about how to run the config program.  I
just didn't want to have a config program worry about which program to run
to configure a conduit, so the config program can just work with the
conduit .so file and figure out how to run its configurator as well as
decide which methods the conduit supports. It seems a little pointless to
have run_configuration though so maybe we should just remove it.  What
does everyone think?

> If its really required, there will be a way to start a capplet from
> the command line, so we can have gpilotd start the configure capplet
> that way.

gpilotd will never start a GUI program so we don't have to worry about it.

> Dr Mike
> 
> 
> -- 
>          To unsubscribe: mail gnome-pilot-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 

Manish Vachharajani
<mvachhar@vger.rutgers.edu>