--===============8171805252117552512== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Nov. 9, 2012, 11:02 p.m., Frank Reininghaus wrote: > > Thanks for taking the time to implement this, but considering that only= two people expressed 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 usefu= l enough to justify that we add code and a GUI option to implement it. 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. > > = > > If some feature request has been reported at bugs.kde.org, that does no= t necessarily 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 number of= votes. I think that Peter's policy was to confirm wish reports when it see= med sort of understandable that the feature might be useful to the reporter= (which does not necessarily mean that the feature is in agreement with htt= p://dolphin.kde.org/philosophy.html). > > = > > One could argue that we should close reports which are probably not goi= ng to be implemented as WONTFIX, but going through all wish reports, evalua= ting one by one if they make sense and then writing something reasonable to= make it clear to the reporter why we are not going to implement it would t= ake an enormous amount of time. Moreover, it would not be a very productive= task. 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 opti= mal, but I don't see a way to resolve this :-( > = > Emmanuel Pescosta wrote: > > Every option makes the settings dialog a bit more complex and harde= r to use, therefore, I prefer to only add options if I see that there is a = very good reason 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/kde= user/kdelibs/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 same name. -> The problem is automatically solved (So we need no additi= onal 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= going to be implemented as WONTFIX, but .... > Hmm, how could we handle that in a good way? - What if we create a li= st of interesting and useful feature request (also with "priority" and addi= tional ideas), so that every Dolphin developer can work on some cool featur= es, which agree with the Dolphin philosophy and get definitely merged into = master. > = > It would be great, if we can setup a wiki or forum for that purpose (= Like KDE brainstorm but Dolphin specific) > = > A "possible" way to create very usable features would be: > 1. Search for interesting feature requests with the "same" target/sco= pe - "Merge" multiple feature requests (Work together on IRC with developer= s 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 ide= as, implementation details, possible usecases ... (Work together on IRC wit= h developers 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 fe= ature, ...) > 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 ;) > = > Mark Gaiser wrote: > I actually changed the titlebar a few releases ago. Please look at th= is review from back then. https://svn.reviewboard.kde.org/r/5178/ > = > Showing the full path in the dolphin decorations is not really desira= ble from my point of view. > = > Emmanuel Pescosta wrote: > Thanks for your reply :) > = > Btw. what do you think about my idea C#2? > = > # Situation: > You have opened multiple tabs - /home/kdeuser/dolphin/src, /home/kde= user/kdelibs/src and /home/kdeuser/kate/src > # Tabs in Dolphin 2.1: (=3D> hmm which folder belongs to dolphin? kde= libs? kate??) > | src | src | src | > # Tabs in a "possible" Dolphin version: (always clear which src folde= r belongs to which project) > | dolphin/src | kdelibs/src | kate/src | > = > Another example: A web developer uses Dolphin for ftp transfer (The w= ebserver 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, ph= otographers, admins, ...). Am I wrong? > = > Hrvoje Senjan wrote: > > I think this is very useful feature for Dolphin users (Developers, = photographers, admins, ...). Am I wrong? > = > I completely agree! Also, i have tested your patch and it works quite= nicely :-) If not commited, it will certainly be handy to have it. I think that the new idea is quite nice, good idea! It requires some non-tr= ivial logic to determine what part of the path to show though (I think that= Peter always had the plan to factor out the tabs into a new class (like in= Konqueror) because DolphinMainWindow is slowly turning into a monster. May= be that should 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 = should 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 red= irection) 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 components.= Then one could go through the components one by one and check for duplicat= es, features that belong together and decide what could be implemented. May= be we can think about that when all bugs have been checked: http://techbase.kde.org/Contribute/Bugsquad/BugDays/Dolphin2012 - Frank ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107268/#review21745 ----------------------------------------------------------- On Nov. 9, 2012, 6:59 p.m., Emmanuel Pescosta wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107268/ > ----------------------------------------------------------- > = > (Updated Nov. 9, 2012, 6:59 p.m.) > = > = > Review request for Dolphin and Frank Reininghaus. > = > = > Description > ------- > = > Patch for feature requests: = > + 88177 - Title bar and tabs in file management display only directory ba= sename = > + 229810 - Show full path in title bar > = > = > This addresses bugs 88177 and 229810. > http://bugs.kde.org/show_bug.cgi?id=3D88177 > http://bugs.kde.org/show_bug.cgi?id=3D229810 > = > = > 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 = > = > Diff: http://git.reviewboard.kde.org/r/107268/diff/ > = > = > Testing > ------- > = > Works for me > = > = > Thanks, > = > Emmanuel Pescosta > = > --===============8171805252117552512== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
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
Testing <= /h1>
Diffs=
|