This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/107268/

On November 9th, 2012, 11:02 p.m., Frank Re= ininghaus wrote:

Thanks fo=
r taking the time to implement this, but considering that only two people e=
xpressed interest in such a feature (one of them in 2004, when Dolphin didn=
't exist at all), I'm not sure if this feature is really useful eno=
ugh to justify that we add code and a GUI option to implement it. Every opt=
ion makes the settings dialog a bit more complex and harder to use, therefo=
re, I prefer to only add options if I see that there is a very good reason =
to do it.

If some feature request has been reported at bugs.kde.org, that does not ne=
cessarily mean that it should be implemented, not even if it's marked a=
s NEW. I'm sorry if there was a misunderstanding there! Note that bugs =
can be confirmed in several ways, one of them is by getting a certain numbe=
r of votes. I think that Peter's policy was to confirm wish reports whe=
n it seemed sort of understandable that the feature might be useful to the =
reporter (which does not necessarily mean that the feature is in agreement =
with http://dolphin.kde.org/philosophy.html).

One could argue that we should close reports which are probably not going t=
o be implemented as WONTFIX, but going through all wish reports, evaluating=
 one by one if they make sense and then writing something reasonable to mak=
e it clear to the reporter why we are not going to implement it would take =
an enormous amount of time. Moreover, it would not be a very productive tas=
k. Therefore, I'm neither willing to spend the little time that I have =
to work on Dolphin on that, nor will I ask someone else to help with that. =
Yes, the "feature requests at bugs.kde.org" situation is very far=
 from optimal, but I don't see a way to resolve this :-(

On November 10th, 2012, 5:16 p.m., Emmanuel Pescosta wrote:

> Ever=
y option makes the settings dialog a bit more complex and harder to use, th=
erefore, I prefer to only add options if I see that there is a very good re=
ason to do it
Yes, I agree with you.

A possible solution for this problem:
# Situation:
 You have opened multiple tabs - /home/kdeuser/dolphin/src, /home/kdeuser/k=
delibs/src and /home/kdeuser/kate/src
# Tabs in Dolphin 2.1:
 | src | src | src |
# Tabs in a "possible" Dolphin version (Current tab name is also =
used for the window title):
 | dolphin/src | kdelibs/src | kate/src |

Dolphin does automatically recognize if there are multiple tabs with the sa=
me name. -> The problem is automatically solved (So we need no additiona=
l gui option) -> Very useful feature for the Dolphin user Simon ;)

Do you like this idea?

> http://dolphin.kde.org/philosophy.html
Interesting :)

> One could argue that we should close reports which are probably not go=
ing to be implemented as WONTFIX, but ....
Hmm, how could we handle that in a good way? - What if we create a list of =
interesting and useful feature request (also with "priority" and =
additional ideas), so that every Dolphin developer can work on some cool fe=
atures, which agree with the Dolphin philosophy and get definitely merged i=
nto master.

It would be great, if we can setup a wiki or forum for that purpose (Like K=
DE brainstorm but Dolphin specific)

A "possible" way to create very usable features would be:
1. Search for interesting feature requests with the "same" target=
/scope - "Merge" multiple feature requests (Work together on IRC =
with developers and users)
2. Think about it!!! (Work together on IRC with developers and users)
3. Write a wiki/forum article about it and add mock-ups, personal ideas, im=
plementation details, possible usecases ... (Work together on IRC with deve=
lopers and users)
4. Other developers/users/ui-experts/... can now give their feedback about =
it (additional ideas, better mock-ups, better way to implement the feature,=
 ...)
5. Developers who are interested in this feature start to implement it
6. Other developers/users/experts can now test the feature -> feedback
7. Merge it into master and ship it =

8. HAVE FUN WITH A NEW AWESOME (and well studied) FEATURE ;)

On November 11th, 2012, 9:15 p.m., Mark Gaiser wrote:

I actuall=
y changed the titlebar a few releases ago. Please look at this review from =
back then. https://svn.reviewboard.kde.org/r/5178/

Showing the full path in the dolphin decorations is not really desirable fr=
om my point of view.

On November 11th, 2012, 10:55 p.m., Emmanuel Pescosta wrote:

Thanks fo=
r your reply :)

Btw. what do you think about my idea C#2?

# Situation:
 You have opened multiple tabs - /home/kdeuser/dolphin/src, /home/kdeuser/k=
delibs/src and /home/kdeuser/kate/src
# Tabs in Dolphin 2.1: (=3D> hmm which folder belongs to dolphin? kdelib=
s? kate??)
 | src | src | src |
# Tabs in a "possible" Dolphin version: (always clear which src f=
older belongs to which project)
 | dolphin/src | kdelibs/src | kate/src |

Another example: A web developer uses Dolphin for ftp transfer (The webserv=
er and the local pc have the same folder structure) =

# Dolphin 2.1: =

 | image | image | (Hmm which image folder is on the server/local pc?)
# "Patched" Dolphin: =

 | Developing/website/images | Server/website/images |

I think this is very useful feature for Dolphin users (Developers, photogra=
phers, admins, ...). Am I wrong?

On November 11th, 2012, 11:07 p.m., Hrvoje Senjan wrote:

> I th=
ink this is very useful feature for Dolphin users (Developers, photographer=
s, admins, ...). Am I wrong?

I completely agree! Also, i have tested your patch and it works quite nicel=
y :-) If not commited, it will certainly be handy to have it.

I think tha=
t the new idea is quite nice, good idea! It requires some non-trivial logic=
 to determine what part of the path to show though (I think that Peter alwa=
ys had the plan to factor out the tabs into a new class (like in Konqueror)=
 because DolphinMainWindow is slowly turning into a monster. Maybe that sho=
uld be done before implementing the "tab title" idea). Note that =
the URLs of *all* tabs must be checked to determine what part of the path s=
hould be shown on the title of a particular tab. This means that every tab =
title change (new tab, close tab, tab title change due to a KDirLister redi=
rection) must therefore trigger a "tab title check" for all tabs.

Your idea to scan bugs.kde.org for interesting features is also good. A fir=
st step might be to reassign all 'general' wishes to meaningful com=
ponents. Then one could go through the components one by one and check for =
duplicates, features that belong together and decide what could be implemen=
ted. Maybe we can think about that when all bugs have been checked:

http://techbase.kde.org/Contribute/Bugsquad/BugDays/Dolphin2012

- Frank

On November 9th, 2012, 6:59 p.m., Emmanuel Pescosta wrote:

Review request for Dolphin and Frank Reininghaus.

By Emmanuel Pescosta.

Updated Nov. 9, 2012, 6:59 p.m.

Descripti= on

Patch for feature requests: =

+ 88177 - Title bar and tabs in file management display only directory base=
name =

+ 229810 - Show full path in title bar

Testing <= /h1>

Works for me

Bugs: 88177, = 229810

Diffs=

dolphin/src/dolphinmainwindow.cpp (11e03d0= )
dolphin/src/settings/dolphin_generalsettings.kcfg (849a9c7)
dolphin/src/settings/general/behaviorsettingspage.h (7a9c2f0)
dolphin/src/settings/general/behaviorsettingspage.cpp (cbbde1d)

View Diff

Descripti= on

Testing <= /h1> Works for me Bugs: 88177, = 229810

Diffs=

Testing <= /h1>

Works for me

Bugs: 88177, = 229810