Re: Split/dual pane view again (but this time with code)
- From: Alexander Larsson <alexl redhat com>
- To: Holger Berndt <berndth gmx de>
- Cc: nautilus-list gnome org
- Subject: Re: Split/dual pane view again (but this time with code)
- Date: Tue, 03 Mar 2009 10:15:54 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]