Bug 326951

Thanks for the report. If I understand you correctly, you suggest that we don't make an inactive split view active (this is what causes the 'cd' in the terminal) when dropping an item inside it. I'll update the summary and severity accordingly.

BTW, the current behavior has been implemented with this patch:

https://git.reviewboard.kde.org/r/110167/

@Frank Reininghaus 
Not "...when dropping an item inside it" but "...when dragging an item from it"(if that's not the same meaning ;)
If you checkout the URL attached from the report you should got the idea
Anyway, thanks for helping to make Dolphin better!

(In reply to comment #2)
> Not "...when dropping an item inside it" but "...when dragging an item from
> it"(if that's not the same meaning ;)

OK, thanks for the clarification. In that case, I'm afraid this is a WONTFIX. If you click into a view, no matter if you do it to drag something from the view or for some other reason, this view is activated, and I don't think that changing this would be a good idea. Sorry about that.

@Frank Raininghaus
Since I have no knowledge on how it's work, the following is my thought of the patch
if(user drag an item from the inactive split-view)
    if(the destination of the dragged item is still in the inactive split-view)
        makeSplitViewActive();
    else
        doNothing();

It the behavior didn't change then It will limit how user can make use of the terminal panel(e.g. Make the path of the object in the inactive split-view become command's argument of terminal panel which working directory is in the active view).

(In reply to comment #4)
> @Frank Raininghaus
> Since I have no knowledge on how it's work, the following is my thought of
> the patch
> if(user drag an item from the inactive split-view)
>     if(the destination of the dragged item is still in the inactive
> split-view)
>         makeSplitViewActive();
>     else
>         doNothing();

Please note that we have a very simple solution for the view activation on mouse press: as soon as a mouse button is pressed while the view is hovered with the mouse, it is activated. We don't even need much code inside Dolphin for that because the "an item gets the focus once a mouse button is pressed above it" idea is the standard in every single application built with Qt (or most likely, any other toolkit out there).

If I understand you correctly, you suggest that do not activate the view on mouse press, but much later, on mouse release. Fighting against the standard behavior that is implemented in the libraries that we use would require a lot of complex and very bug-prone code that will require a lot of maintenance in the future.

> It the behavior didn't change then It will limit how user can make use of
> the terminal panel(e.g. Make the path of the object in the inactive
> split-view become command's argument of terminal panel which working
> directory is in the active view).

I understand that the current behavior is not what you want, but please understand that

(a) Changing it is *extremely* difficult, and

(b) the current behavior has been like that most likely since the first release of any default KDE file manager that supports split views, but now is the first time that anyone complains about it.

This is why it's not going to be changed, sorry about that.

@Frank Raininghaus
I can understand that, thanks for your explanation.

Created attachment 83321 [details]
Image of Kate's relating option

@Frank Raininghaus
I changed my mind.
Is is possible to add a option(and even an button on toolbar) like in Kate to disable the synchronization of terminal panal with current active view?

Stop the synchonization will also help resolve this issue ;)

There is already a report about adding such an option (bug 306381).

But please note that we already provide two different ways to open a terminal for the current directory:

(a) The Terminal Panel, which can be opened, e.g., by pressing F4, and which is always synchronized with the current URL of the active view.

(b) An external terminal, which can be opened with Shift+F4, and which is not synchronized with the view.

So basically you can have already what you want, and I'm not sure if adding an option to (a) to make it behave a bit more like (b) really makes sense. Options always make the UI more complex and introduce multiple code paths, which make future maintenance and debugging considerably harder.

I think that the Kate situation migt be different. I don't really use the embedded terminal in Kate, but if I look at my own usage of Kate, I can understand perfectly why one might not want to have its directory synchronized with the current file (I often work with different Dolphin source files, which are split into multiple directories, but I want the 'make' command to always be run in the top-level directory).

@Frank Reininghaus
The main reason I need the feature(as per the discussion here already mentioned: http://www.plurk.com/p/jd62au however its in zh_TW) is "I don't want to open another external terminal (for doing stuff in Dolphin CLI-ly)"

And since there's another bug 306381 currently there's 2 handy(handy at least to reporters ;) ) reasons to add this feature to Dolphin.  Please consider it if it didn't cause serious issue in development. :)

(In reply to comment #9)
> "I don't want to open another external terminal (for doing stuff in Dolphin CLI-ly)"
> 
> And since there's another bug 306381 currently there's 2 handy(handy at
> least to reporters ;) ) reasons to add this feature to Dolphin.  Please
> consider it if it didn't cause serious issue in development. :)

*Every* new option causes serious trouble for the people who develop, maintain, and debug the software (and please note that these people are all volunteers who work on Dolphin in their extremely limited spare time). Therefore, there must be a *very* good reason why a new option should be added.

*** This bug has been marked as a duplicate of bug 306381 ***