Re: Regarding Nautilus scripts

[Andrew Sobala <aes gnome org>]

On Mon, 2003-06-09 at 17:10, Eugenia Loli-Queru wrote:
> Rob wrote:

It was me, actually :-)

> > Shouldn't it be under an "Archive" submenu, if anything? Why should a
> > user have to know the code is provided by a different application to
> > core nautilus?
> 
> That's what I am saying. The user shouldn't know that! This is why this
> functionality should be done by a small binary/library FOR Nautilus and NOT
> by an external third party application.

"Addons" are small third party binary applications for nautilus.

> Third party applications they should
> be allowed to install their addon FOR Nautilus as a .so lib file on a dir
> like /opt/gnome/bin/nautilus-addons. E.g. File Roller should add there its
> stuff. But if someone wants to write an addon for Nautilus that it is not
> part of another big app, they should be allowed to do so. In fact, it is
> much easier to do that than using a third party app as a client for nautilus
> stuff.

Yes, they can. The app that is the addon can be as large or small as you
design it.

> > And if we only have 1 archive menu option (which I agree we should), a
> > submenu makes no sense.
> 
> In this case, yes, 1-2 options should not have their own submenu. But as I
> explained on weekend, there should not only be one option for general
> extensibility. I already metnioned 10 good candidates for addons!
> FileRoller's stuff is only 1-2 of the lot that needs to go there and extend
> the functionality of Nautilus!

User installs Red Hat Linux, with their selected plugins. User right
clicks on a file in nautilus. He shouldn't have to distinguish between
"Function done by nautilus" (main context menu) and "Function done by
other applications (addons)" (a submenu). It's a silly distinction.

If the submenu is because the main context menu gets too cluttered, the
submenu will be cluttered too and we would have a basic design problem.
(That may be the case, but a separate thread.)

> Rodrigo wrote:
> 
> >the location is totally transparent, since we know where they are via the
> installed .server files related to each component (= addon).
> 
> You know where they are placed via these .server files. Does the user know?
> How would he be able to place one manually if his ./configure screwed up, or
> if he simply wants to uninstall one, or... How is the user going to deal
> with this? The easiest way is to have a "Settings..."  popup window listing
> all addons with checkbox next to them, and unchecking their checkbox it will
> hide the equivelant addon. But if a manual way should be there, there should
> be a specific addon dir where the user physically can move around .so addon
> files. It is just so much cleaner to have everything in one place instead of
> scattered all over the place and only determine their location when reading
> that .server file...

Like all *nix applications, files end up everywhere and aren't meant for
user uninstallation. Lots of apps dump stuff in /usr/bin, /usr/share,
/usr/lib.... it's what package management is for.

And it's unlikely that bonobo is going to be redesigned so users can
easily move about shared libs.

-- 
Andrew Sobala <aes gnome org>

"We made GNOME-VFS support smb: and nfs: URIs. And we made OOo support
GNOME-VFS. Booyakasha!" -- nat