On Sat, 2009-02-28 at 15:57 +0100, Holger Berndt wrote: > On Di, 24.02.2009 10:48, Alexander Larsson wrote: > >As a maintainer of a distro I don't quite see it the same way. There > >will just be lots of pressure to install the extensions by default, just > >like there is pressure to add the open terminal extension (its in fact > >installed by default in RHEL). > > While I can understand your reasoning, I am not sure what conclusion to > draw from your point of view. Is extensibility and plugin-support a bad > thing just because somebody could implement an extension that your > customers/users really like, who in turn could put social pressure on > the distributor? Isn't, on the other hand, such a pressure a clear vote > that the existence of the extension is very important?
I don't exactly have a "conclusion" as such. I merely wish to point out the inherent problem with making things "plugins" as a way of "solving" the problem that not everyone wants a feature. Such a solution looks good in the abstract, but in practice it is not so clear cut. For instance, plugins are generally installed system-wide, so either nobody gets it or everyone gets it. If its not installed its very non-obvious how to get the feature or that its even availible. If its installed the original problem (that not everyone wanted the feature) is back. The "obvious" solution to this is the "pluging manager" that lets you enable/disable each plugin and configure it. Witness for instance the evolution Edit->Plugin menu item. While the use of plugins there might be an advantage from a programmer/maintainer point of view its exceptionally bad from a user interface point of view. Since all these features are for all intents availible in the app this dialog is more or less another config dialog, and a bad one. A carefully designed and structured config dialog would be vastly easier to navigate and understand. Anyway, this is not really the main point here. I'm just ranting a bit, because a lot of people seem to think that "plugins" is the final solution to a lot of problems, when its IMHO a problem in itself. > >I guess one way to make this less weird is to always have a "copy to" > >submenu, similar to the dolphin one. > > I am not sure about which menu in Dolphin you're talking. I didn't see > a "copy to" submenu. Sorry, that was in konqueror, not dolphin. In the context menu. > >It would have home, root, maybe > >some bookmarks/mounts and then let you dive down into these as menus. > >Then we could just add a "other pane" menu item in the split view case. > >That would make it more obvious that this is a standard operation with a > >different way of specifying the target. > > So we would have "Edit -> Copy to" and "Edit -> Move to" submenus with > default targets. The "Edit -> Move to trash" menu item could move in > there, too. That sounds very good to me. Yeah, something like that. Also in the context menu. I don't think we should move the move to trash item. Even though the wording and the lowlevel action is a "move" its really more of a "delete" operation from a user point of view. -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
