Re: Regarding Nautilus scripts

[Bob Smith <bob thestuff net>]

For B, I'm thinking you can do something similar to how xpm's work. Make
the .server file "include"able into the bonobo library and have a function
that returns the data. oaf can then get the .server info from the library
by using some equivilent of dlsym.

On Tue, 10 Jun 2003, Sriram Ramkrishna wrote:

> Okay, I think I understand the situation.   What she's looking for is:
>
> a) a methodology to be able to add extensions (using bonobo) to context
>    menu.  How and where it's put in the menus is a matter of user testing
>    and conforming to HIG.
>
>
> b) the method in which it's being installed needs to be user friendly.
>    That means:
>
>    a) bonobo needs to look in a particular place.  bonobo would either
>    have to have a default place to look when it looks at user component
>    (like how apache does it) or you could do something hideous like
>    sticking it in gconf. ;)
>
>    The server file does some other things right other than tell where
>    the component is located?  Looking at the file it looks like it creates
>    a description on how the component will be used. (ie mime type etc)
>
>    I'm not sure if thats easily translatable to being able to just drop
>    it into some directory.  It looks like the component has to embed that
>    information into itself.
>
>
> Just some thoughts on the subject.
>
> sri
>
>
> On Tue, Jun 10, 2003 at 03:02:31PM -0700, Mason Kidd wrote:
> > That's why things like this should be distributed as packages or source
> > tarballs.  The locations of things get determined by wonderful things
> > like configure scripts and
> > pkg-config.
> >
> > Mason Kidd, CCNA
> > IT Customer Support Engineer II
> > BEA Systems, Inc.
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob Smith [mailto:bob thestuff net bea com]
> > > Sent: Tuesday, June 10, 2003 12:03 PM
> > > To: Mason Kidd
> > > Cc: Eugenia Loli-Queru; nautilus-list gnome org;
> > > desktop-devel-list gnome org
> > > Subject: RE: Regarding Nautilus scripts
> > >
> > >
> > > Doesnt a .server file need to specify the location? If so,
> > > then its not a
> > > drop. Its a, put the file in the directory, put the so in a directory,
> > > edit the .server to reflect the location of the .so. Its the last part
> > > that breaks the ease of use.
> > >
> > > ---  Bob Smith <bob thestuff net>  ---
> > > ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++
> > > ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
> > >
> > > On Mon, 9 Jun 2003, Mason Kidd wrote:
> > >
> > > > But I think that this functionality pretty much already exists.  You
> > > > drop the .server file in a special directory (/lib/bonobo/servers
> > > > usually), and Bonobo registers the component. It doesn't
> > > matter where
> > > > you put the .so file, because the .server file tells Bonobo
> > > where the
> > > > .so file is.  So how is this more difficult than MacOS or BeOS?
> > > >
> > > > It seems to me that your only real complaint is the
> > > cluttering up of the
> > > > top level Nautilus menu.  This could be easily alleviated
> > > by creating a
> > > > submenu (Extensions or whatever), and have components'
> > > menus be placed
> > > > in there (like your mock-up).
> > > >
> > > > As an aside, in about an hours worth of work, I created a Bonobo
> > > > component to do the Open Terminal Here... functionality.
> > > I've gotten
> > > > all the code written, just finishing up the compiling and
> > > installing.
> > > > And I've never done any programming "of Nautilus internals"
> > > or anything
> > > > like that.  So it's actually very easy to create "Nautilus addons".
> > > > Anyone that knows C and XML can do it just by looking at
> > > some example
> > > > code (I looked at the file-roller component source).
> > > >
> > > > Mason Kidd, CCNA
> > > > IT Customer Support Engineer II
> > > > BEA Systems, Inc.
> > > > Kirkland, WA
> > > > 425-896-4194
> > > > Seattle, WA
> > > > 206-926-2957
> > > > Cell 206-295-7687
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Eugenia Loli-Queru [mailto:eloli hotmail com]
> > > > > Sent: Monday, June 09, 2003 5:18 PM
> > > > > To: nautilus-list gnome org; desktop-devel-list gnome org
> > > > > Subject: Re: Regarding Nautilus scripts
> > > > >
> > > > >
> > > > > > On a related note about .server files, and I think this is
> > > > > sort of where
> > > > > > Eugenia is trying to go is, while the .server file
> > > needs to be in a
> > > > > > spacific directory, a .so plugin does not need to be in
> > > a spacific
> > > > > > location. So there is two parts to a plugin. A .server file
> > > > > and a .so
> > > > > > file. One of the things that was very nice about MacOS < X
> > > > > (and maybe X, I
> > > > > > havent used X) was that you could put an extention in
> > > (one file) a
> > > > > > special directory and it was registered. And when you
> > > were done with
> > > > > > it, you just removed it from the directory. Maybe an
> > > > > extention library
> > > > > > could be added to bonobo(-activation) so that a .server
> > > > > file could be
> > > > > > described in a .so file (Maybe as a function??) and have a
> > > > > program that
> > > > > > pulls out the .server and registers it with
> > > > > bonobo-activation. (hmm...
> > > > > > this sounds familior. Doesnt activex do something like
> > > > > this...). Then
> > > > > > have nautilus have a special directory for plugins such
> > > that, if you
> > > > > > place a .so file in that directory, it automatically
> > > > > registeres the plugin
> > > > > > and when you remove it, it unregisteres it. This would add
> > > > > functionality
> > > > > > similar to what MacOS has. Also, since its not nautilus
> > > spacific, it
> > > > > > would also be an easy way to install plugins for other
> > > > > bonobo-activation
> > > > > > programs. (Maybe gedit?)
> > > > >
> > > > > That's exactly what I was talking about, regarding the
> > > > > location. MacOS is
> > > > > not the only OS that does that, BeOS does that too with
> > > > > Tracker's addon. You
> > > > > pop their .so files to the correct location as defined by
> > > > > pkgconfig (if you
> > > > > want to install them manually that is) and voila, the addon
> > > > > is there! No
> > > > > .server files or .so files all over the place. Just a
> > > simple .so or
> > > > > executable, these applets are small apps anyway and when they
> > > > > are not, let
> > > > > the .so file to call the big app (e.g file roller). On BeOS,
> > > > > you don't even
> > > > > have to restart the file manager for Tracker to find the
> > > > > newly placed addon,
> > > > > the live queries system will tell Tracker that a new
> > > addon was placed,
> > > > > automatically.
> > > > >
> > > > > Underlying OS + integration is your friend.
> > > > >
> > > > > Eugenia
> > > > > --
> > > > > nautilus-list mailing list
> > > > > nautilus-list gnome org
> > > > > http://mail.gnome.org/mailman/listinfo/nautilus-list
> > > > >
> > > > _______________________________________________
> > > > desktop-devel-list mailing list
> > > > desktop-devel-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > > >
> > >
> > > _______________________________________________
> > > desktop-devel-list mailing list
> > > desktop-devel-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > >
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
> --
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>