Dolphin change proposals

[Parker Coates]

On Sun, Jan 10, 2010 at 12:28, todd rme wrote:
> On Sun, Jan 10, 2010 at 1:43 AM, Parker Coates wrote:
>> Personally, this strikes me as overkill. Drag and hover already opens
>> the tab which is a lot more flexible as it allows you to drop on
>> subfolders. Others might disagree.
>
> First of all, by that argument we shouldn't have the menu when we are
> dropping on a folder (which you also enter after a short delay).
>
> Second, as I said, the behavior is inconsistent.  For every other
> representation of a folder in dolphin, dropping on it brings up a
> menu.  That is at least 4 other places.  Only the behavior of tabs is
> different.  I think this sort of inconsistent behavior is confusing.

This is where our opinions differ. In my mind a tab isn't a
"representation of a folder", but a purely layout related user
interface element. The fact that a single tab can contain more than
one folder reinforces that notion. Right clicking on a tab doesn't
give you the same options that right clicking inside a folder does.

I'm not saying I'm right and/or you're wrong.

> Finally, it takes a lot longer to do things the way you describe way.
> The "short delay" isn't that short, then you have to maneuver your
> mouse back into the folder area, then you have to find and maneuver
> your mouse to a blank area on the folder (this is not always an easy
> task depending on the size and spacing of your icons).  And in the
> end, you still end up with the menu.  What's more, you are now in the
> new tab, meaning you have to then navigate back to the previous tab.
> All of this takes a significant amount of time compared to just
> dropping it right on the tab, especially if you are trying to move
> files to multiple different tabs.
>
> And before you ask, when you have a split view open in the destination
> tab, the active side will be the one to receive the files.  This
> should not be unexpected behavior, since the tab's title is also the
> name of the active tab.  That being said, if people think it would be
> better I might try giving people the option of sending the file to
> either or both of the views (I don't know how much harder that would
> be).
>
>> I think this is a bad idea. Across KDE actions are applied to selected
>> items, not hovered ones. If you did this, then why not
>> hover-and-delete or hover-and-copy or hover-and-enter-to-open, etc.
>> What would the benefit be?
>
> I see how this is inconsistent behavior, but maybe that should be the
> rule generally?  That is outside of my ability at this point, though.

I think it's very important to keep the role of selection very clear.
It's easy to forget how much trouble novice users have conceptually
distinguishing between hover, selection and focus. Anything that blurs
those lines is only asking for trouble.

> The reason I specifically mentioned renaming is simply because I have
> often wished I didn't have to click something in order to rename, I
> have never had that thought for other actions.  It is also low-risk,
> because F2 is hard to hit by accident and if someone does so nothing
> will happen unless they then type and then hit enter, and a simple esc
> will cancel anything they have done.
>
> As for the benefit, it is quicker and easier.

It might be quicker, but I don't buy that it's easier. With the
exception of high-end video games, desktop users are rarely expected
to coordinate mouse positioning with keyboard key presses. The
paradigm is [aim with mouse -> click to perform action] or [aim with
mouse -> click to select -> keyboard/button/toolbar/menu to perform
action]. [aim with mouse -> keyboard to perform action] just isn't
really done. I really don't think the small potential benefit here is
any where near the cost of breaking such a fundamental paradigm.

>>> If you select multiple files of different types, then right-click it
>>> will have an "open with default applications" or something like that,
>>> and all the files will then be opened with their own default
>>> application.
>>
>> Do you have an example use case?
>
> Sure.  For instance, say you have a folder with several pdf files for
> documentation and several cpp and h files for source code.  You want
> the code open in kate so you can work on it and the pdf's open in
> okular because you need to refer back to some of the more obscure
> aspect of the api.  Currently this would take at least 2 actions
> depending on how you do it (dolphin isn't very good at detecting when
> multiple files with different extensions are all opened by the same
> program by default, a bug I was planning to fix).
>
> A similar example is writing a paper and having pdf's of references
> opened at the same time, or a text document and a spreadsheet.
>
> All of these would currently require two different open actions.  I
> don't see why it would be a bad thing to let users open them all at
> one time.

Sorry. I wasn't understanding your original proposal. As Harsh
mentioned, Dolphin already has the functionality you're describing via
the keyboard. Just select the files and hit enter. You're just
proposing to add this action to the context menu. I think this is a
good idea, but I would lean toward just "Open" as the action name.

> What about the other ideas?  I am not sure whether the lack of
> comments indicates approval, ambivalence, or uncertainty.

Mostly just no opinion. I never use groups in Dolphin, so I don't
really feel entitled to comment on them. An actions panel doesn't seem
like a great idea to me, but as long as it isn't present by default,
I'm probably not going to complain.

Anyway, I should again point out that these are just my personal
opinions as a Dolphin user. I'm not a member of the Dolphin team, so
my thoughts hold no real weight. Which reminds me, you should probably
take this to the kfm-devel list as that's a better place to discuss
this with real Dolphin developers.

Parker