If you allow to open a folder inside the folder view, how can you go back? It should be even added a button for going back... 

Like I said, the plasmoid could automatically go back to the default folder if it's left unused for some time. And/or there could be a button in the plasmoid that takes the user back to the default folder.

Although returning after a certain amount of time is an okay idea, I have some alternatives.

My favorite would be to fuse folderview and quickaccess.  So when you click on a folder in folderview, it acts as though you were clicking a quickaccess applet and pulls up the quickaccess navigator inside that folder.  This would go away when you click somewhere other than the quickaccess navigator.  

The other would be to open a smaller folderview inside the folderview you clicks.  Parts of the original folderview would be shown, and once again it would close when you click outside of the smaller folder.

>>If user opens folder inside folderview, the folder gets opened in a filemanager, and not inside the folderview itself. This is quite jarring experience and diminishes the usefulness of folderview. What's the point of folderview if it instantly relies on a filemanager, even if it just something as simple as opening a folder? 

I think your wish is wrong in concept. Folderview isn't a substitute of a filemanager, folderview is just a view. It is supposed to work like that. Just like kdesktop was a view of the ~/Desktop files, folderview is a view of any folder you want, just that. The basic difference now is that you can have many view you want on the desktop (or even have a ~/Desktop view like the old desktop, using folderview - there will be an option to do that on KDE 4.2).

I don't see the usefullness of folderview dismished at all, now you can have multiples views on the desktop (even network folders views, nepomuk vies etc).. move a file from one folderview to another, by "dragging and dropping" ...thore are the usefulness! Although folderview can do some things filemanagers do (like delete folder, or move folders ) it isn't a lightweight filemanager. 

I think some feature like those on Nuno's mockups 

http://nuno-icons.com//images/estilo/imagefolders2.png 

are the ones that have to be implemented, because they don't change the concept of things, folderview keep being a view, with more options (I think those features will be implemented someday).

By the way, you can have a filemanager as a plasmoid now if you use embeded windows plasmoid, take a look at the screenshot I made. I am using KDE 4.2 trunk and plasmoids from kdeplasma-addons and playground.

Created attachment 28393 [details]
"Dolphin embedded" plasmoid (using embedded window plasmoid)

Nice! :-)

"I think your wish is wrong in concept. Folderview isn't a substitute of a filemanager, folderview is just a view."

That might be. But we shouldn't tie our hands with dogmatism. We should figure out what makes sense. If folderview can't handle folders, it means that it's functionality is quite limited, since it would instantly rely on Dolphin, as opposed to being able to anything by itself.

"I don't see the usefullness of folderview dismished at all,"

The fact that folderview does not open open folders does diminish it's usefulness.

"thore are the usefulness!"

I never claimed that the features you listed are not useful. All I said that folderview would be even more useful if it actually managed to open folder by itself.

Yes, folderview is more useful than the "traditional" way of handling things, I never disputed that. All I said is that it could be even more useful.

The idea of folderview is that it displays contents of a folder, correct? Then why couldn't it display the contents of a folder that is opened inside it? It would still be displaying contents of a folder.

"By the way, you can have a filemanager as a plasmoid now if you use embeded windows plasmoid,"

I have no desire to run a full-fledged filemanager as a plasmoid. I'm just asking that folderview should be able to open folders by itself, that's all. If I wanted a full-fledged filemanager, I would run Dolphin.

Quickaccess handles folders just fine. Why couldn't folderview? If you say "folderview is just a view of a folder, that's why", then it means that you are relying on some arbitary definitions, as opposed to thinking how to actually make things better.

Should we limit folderviews functionality, even if adding that functionality is

a) possible
b) wouldn't make the plasmoid worse in any shape or form
c) actually makes the plasmoid better at what it does

?

Well, I think this could be done by implementing a mini file browser plasmoid.

Folderview is a containment (like the panel) that shows files and as a containment it should not be used to browse files (making this with a plasmoid makes more sense). Quickaccess is indeed one of the examples that file browser should be done with plasmoids (since quickaccess is one) but not through containments.

On 4.2, there will be an option to make this folderview containment be the desktop itself (~/Desktop will be the default folder in this case). And yes, it will be possible to put some plasmoid inside this folderview (as a desktop containment). Imagine the mess it would bring to navigate through folder inside the desktop itself. 

Automatically go back to the default folder would just bring complication because:

1) How many time to wait before it goes back to default folder? Make an option for that? Does it makes sense to set a parameter like "time" on something that is supposed to show files and have other plasmoids inside it? 

On a slide show plasmoid it makes sense, for instance. But it isn't a containment.

2) What if I don't want to go back to default folder at all? Some minutes ago , for instance, I set folderview to show (through navigating) , say, My Projects folder.. and now it is showing Home? What happened? 

These are just the two examples I could imagine now.. but I think it could probably complicate things even more...

Navigation should be done through widgets, like trees or breadcrumbs, and that would make more sense on a mini file manager plasmoid.

An user case, imagine you are using folderview as the desktop itself, browser some folders/files ... and it doesn't open dolphin. Where are those links I put on the desktop? Where is the file I saved on desktop? And those I just downloaded from firefox that I set to save downloaded files on ~/Desktop? See?

The problem here is the conception, not dogmas. No one is tied at all with plasma... Your idea is really good.. but the conception is wrong. This should be done by implementing a mini file browser and it would be cool indeed (I would use it).

About the embedded windows plasmoid I showed, well, just showed as a parenthesis... I don't use it at all too... But it shows how you can make many fantastic and even weird things with plasma. 

By the way, the defition I showed about Folderview is not arbitrary at all.. it IS indedd its defitinion/concept. First we should understand the defitions/concepts.. then reporting wishes.

 

OH, and I just saw some grammar mistakes I made while writing these responses... well, English is not my native language and I am still learning.. so sorry for the bad English...

At 1) How many time to wait before it goes back to default folder? Make an option for that? Does it makes sense to set a parameter ... I meant 1) How long do we have to wait before it goes back to default...

Well, I don't want to make this space as a discussion one, since it is for reporting bugs and wishes. I think I made myself clear (as possible) so I am done here.

Sorry for the bad English, peace! 

"Well, I think this could be done by implementing a mini file browser plasmoid."

There's no need for that. folderview already does 95% of what is needed. Quickaccess does 100%, but it's form-factor is different from folderview (Quickaccess is a panel-plasmoid, folderview is a desktop-plasmoid. Why should we have a THIRD plasmoid that does the same thing as those plasmoids do?

"Folderview is a containment"

It can be used as a containment. But it's also a plasmoid.

"Imagine the mess it would bring to navigate through folder inside the desktop itself."

If you use folderview as a containment, it (of course) makes sense to use a filemanager then. But if you use it as a plasmoid, it makes sense to open the folders inside folderview. Besides, this would be configurable.

"An user case, imagine you are using folderview as the desktop itself"

I'm obviously talking about folderview-plasmoid here, not folderview-containment.

"The problem here is the conception, not dogmas. No one is tied at all with plasma... Your idea is really good.. but the conception is wrong. This should be done by implementing a mini file browser and it would be cool indeed (I would use it). "

Why should we keep on re-inventing the wheel here? A mini filebroswer would be more or less identical to folderview as it is. FOlderview already does 95% of the things I would like it to do. Quickaccess does 100%, but it's a panel-plasmoid. Why should we waste time on a third plasmoid, if we could have the desired functionality in folderview-plasmoid itself? We would then have a plasmoid that is for all intents and purposes identical to folderview, except for the tiny difference that it opens folders inside itself, as opposed to using Dolphin....

"There's no need for that. folderview already does 95% of what is needed. Quickaccess does 100%, but it's form-factor is different from folderview (Quickaccess is a panel-plasmoid, folderview is a desktop-plasmoid. Why should we have a THIRD plasmoid that does the same thing as those plasmoids do?"

This is about design. I makes me remind of the old "remove the cashew saga". "Why not remove the cashew? I don't like it!!". Because it breaks the design. Using folderview for something that is not a view, but a browser break its design. When we are on a project, we have to follow some criteria (not dogmas) to create things, otherwise we would create a Frankenstein (something big, that makes everything and don't have identity at all) . Folderview does what it is supposed to do as a view (again), just like those views we create on a Database, for instance... I view is not supposed to substitute the tables or the schema of a database, but to SHOW information from specific tables in specific situations, following specific rules. That's what a view is. (with nepomuk, folderview is behave very very similar to those views on databases). That is the task of the folderview, show on desktop files/folder from a specific folder, obeying specific rules (filtering, nepomuk and all). 

When we clicked on a folder that is on the desktop, it always opened the filemanager (on windows, MAC, KDe, gnome, and etc). I can´ t see what is strange about that. Now, if it was a file manager/browser plasmoid or whatever, I would expect it to open the folder inside it (because it IS the way, by design, it should work).

With the famous cashew was the same thing. The famous cashew is there because it has its task for that containment (the desktop). It is not dogmatism, it's the design. The way to do it (remove the cashew) was to create a plain desktop containment and opensuse guys just did it. Was that VERY difficult? I don't think so. Will it be very difficult to create a File Browser plasmoid, I guess not either... I wouldn't be surprised if this File browser plasmoid was just the folderview with a breadcrumb to navigate (some more lines of code). It is about giving each part a task, a responsability, separate things tasks and responsabilities to make things work in order,with mutualism and with elegance.

Of course we are on a opensource project, so everything you want to make with the code, you can, in theory. So your wish is possible? Yes it is. It will make folderview better?  It will make folderview become a file browser. If it is better or not? Do not know, because they are different things.


"Besides, this would be configurable."

Adding all this configuration adds complication, in pratice. It reminds me of the old konqueror, many things to configure, capable to do many things... but very bloated. For power users, it is indeed great, but for the rest, may be not so interesting. 

That was one of the main reasons to have dolphin and konqueror separated, so why not follow the same design for folder view plasmoid, file browser plasmoid and web browser plasmoid? (Two of them already exists). Separate things and give them specific tasks. 

 "Why should we keep on re-inventing the wheel here? A mini filebroswer would be more or less identical to folderview as it is. 

It wouldn't be reinventing the wheel, we would be giving each plasmoid a specific task and a name that corresponds that task. That's why kparts exists and that's why plasma has dataengines, runners, theming and etc( Make it easier to make many things, without reinventing the wheel). We already does that with menus, for instance. The same engine that "feeds" kickoff, does it for the old style menu. So the same "engine" used for folderview, could be used to make a part of file browser (since browsering is a bit more complicated than viewing).

"Folderview already does 95% of the things I would like it to do."

You would like it to do it, but others may not like it to do it. So why not separate things to make everyone happy? You could say "It can be configured" and we would return to the "konqueror problem". And folderview doesn't do 95% of what a browser does, because it isn't a browser. It does 100% of what it is supposed to do (on 4,2 trunk, which I'm using.. it's perfect). 


"Quickaccess does 100%, but it's a panel-plasmoid. Why should we waste time on a third plasmoid, if we could have the desired functionality in folderview-plasmoid itself? "

I don't see a creation of a new widget as a waste of time. In this case even less, because it would give each horse a name, an ID (folderview for viewing, file browser for navigating).

"We would then have a plasmoid that is for all intents and purposes identical to folderview, except for the tiny difference that it opens folders inside itself, as opposed to using Dolphin.... "

We would be the same (with more elegance and coherence) if a file browser plasmoid is created. But better because it has the correct name.

Well, I think the problem here is the definition of Views and browsers. I would guess that your wish is not going to be fullfilled (the way it is). Not because your idea isn't good (it is indeed very good), but because the way you want,it would have to be implemented in a way that breaks the definition of what a view is. I think a mini browser is more feaseble, coherent with the design and solves the problem. I am not KDE developer (yet) and I don't want to make your idea unusuble, not at all. And let's stop with that dogma thing... plasma is the most flexible existed on a destkop (it even resizes automatically), so if somebody want to create this "folderview", can just do that, but I don't think kde team is gonna do it (probably I'm gonna create a file browser plasmoid using python). But maybe I am wrong? That's the beautifulness of OpenSource.

"This is about design. I makes me remind of the old "remove the cashew saga". "Why not remove the cashew? I don't like it!!"."

Removing the cashew was about removing functionality, not adding it.

"Using folderview for something that is not a view, but a browser break its design."

It does not. Only thing it "breaks" is the narrow, arbitary definition that folderview should not open folders.

"When we clicked on a folder that is on the desktop, it always opened the filemanager "

Yes, a folder that is _on the desktop_. Folders that are in folderview are not on the desktop, they are inside the folderview. If you used folderview as a containment, then they would be on the desktop.

"Now, if it was a file manager/browser plasmoid or whatever, I would expect it to open the folder inside it (because it IS the way, by design, it should work). "

Again, you are stuck in dogma. You have this strange idea that because folderview is just a "view", it should not open folders. Surely you see that stubbornly sticking to that definition would prevent improving folderview?

"It will make folderview become a file browser. If it is better or not? Do not know, because they are different things. "

The difference between the two is miniscule. Seriously, the only difference between the two is whether folderview open folders inside itself, or with Dolphin. That is the only tangible difference. I don't really understand why you are so fanatically against this change.

"You would like it to do it, but others may not like it to do it."

I don't really see why. They could just keep on using folderview as it is today. For them, nothing would change. But thise who would like to use folderview in a slightly different way, could do so.

"It wouldn't be reinventing the wheel, we would be giving each plasmoid a specific task and a name that corresponds that task."

If you make plasmods too specialised, you will face a situation where you have dozen plasmoids, all doing the exact same thing in a slightly different ways.

And what about the name? Are you now saying that folderview should only view folders, because it's called folder_view_?

"We would be the same (with more elegance and coherence) if a file browser plasmoid is created. But better because it has the correct name. "

So you ARE saying that folderview should only view folders, because it's called folderVIEW? That's like saying app called RSSnews should not handle Atom-feeds at all.

"Well, I think the problem here is the definition of Views and browsers. I would guess that your wish is not going to be fullfilled (the way it is)."

Actually, looking at the mailinglist, it seems that there is a desire among the developers to merge quickaccess and folderview. As they say, quickaccess is folderview in a panel form-factor.

Quickaccess opens folders, folderview does not.

I really don't see the problem here. I would understand if someone told me techical reasons why it couldn't be done (but it could be done, as quickaccess shows us). But instead I'm being told that it shouldn't be done because folderview is called folderVIEW, and it's only supposed to view folders. By that logic you should only be able to view folders with it, but not do anything with the files inside (like open or move them), since you are only supposed to VIEW them.

Break, break, break... :-)

Augusto doesn't like the idea to change the target of folder view, instead Janne would like to see it extended with the possibility of use it like a file browser, did I understand right?

If this is the point, you (Augusto and Janne) will continue to write your opinions without an end... :-) :-) :-) :-) 

I suggest to Janne to write some use cases where navigating files through a plasmoid is useful. I suggest also to Augusto to write when this is not useful.

(I know you've already wrote when and when not on this long discussion, but, please, a short brief could be useful).

From this point the actual system can be analyzed trying to understand if this issue will be useful for users, leaving on a side our personal wishes.

Do you agree?

Answering Jannes arguments Janne:

"So you ARE saying that folderview should only view folders, because it's called folderVIEW? That's like saying app called RSSnews should not handle Atom-feeds at all. "

YEEEESSSSS, exactly that. It is called folder view because it is a view. As makes sense to call quickaccess, since it gives quickaccess to all the folders you want. Well, I expect something that's called RSSNews to atom-feeds, since that's what RSS is about, isn't it? As well as I expect a folderview to show me a view of a folder.

"The difference between the two is miniscule. Seriously, the only difference between the two is whether folderview open folders inside itself, or with Dolphin. That is the only tangible difference. I don't really understand why you are so fanatically against this change." 

Can't say if technically this difference is going to be miniscule, in terms of code. One thing I know is that it would have to add a way to navigate back and foward (some widget of the solution you proposed).

"But instead I'm being told that it shouldn't be done because folderview is called folderVIEW, and it's only supposed to view folders. By that logic you should only be able to view folders with it, but not do anything with the files inside (like open or move them), since you are only supposed to VIEW them. "

Well, I think that's a little difference here. I think folderview is called like that because it shows a view of a folder, not view folders. That's why you have to choose one on the configuration, the difference is very very miniscule. Look, I am taking view definition as that one of a database http://en.wikipedia.org/wiki/View_(database)" as describe on wikipedia. Of course we have to take the proportions , because it is not a database that folderview manipulates (although I think we can get pretty close result with nepomuk). The queries would be made by filtering and nepomuk.


"Again, you are stuck in dogma. You have this strange idea that because folderview is just a "view", it should not open folders. Surely you see that stubbornly sticking to that definition would prevent improving folderview? "

The dogma thing again.. oh boy, let's stop with it.. I could use this argument to say that you are stuck to the dogma that folderview have to browser folders. It doesn't say anything and doesn't bring much to the discussion. We are not talking about religion here.. :D

"Actually, looking at the mailinglist, it seems that there is a desire among the developers to merge quickaccess and folderview. As they say, quickaccess is folderview in a panel form-factor. " 

Well, great then... as I said before, I could be wrong and that's the beautifulness of opensource. Would be less confusing than navigate some files, waits some random (or defined) seconds and come back to beginning again automatically (I can't see my gramma using and understanding this...).

"I really don't see the problem here. I would understand if someone told me techical reasons why it couldn't be done (but it could be done, as quickaccess shows us). But instead I'm being told that it shouldn't be done because folderview is called folderVIEW, and it's only supposed to view folders. By that logic you should only be able to view folders with it, but not do anything with the files inside (like open or move them), since you are only supposed to VIEW them. "

It is not only about technical reasons. Technically, plasma can do pretty much everything (like make folder view atom-feeds, reads emails and notifies me when I receive a kopete message). Technically it can be done, what I am trying to explain here is that, following the design, maybe it would be more coherent to create a mini file browser instead, just that .

"But instead I'm being told that it shouldn't be done because folderview is called folderVIEW, and it's only supposed to view folders."

No, it is supposed to show a view of an specific folder following specific rules (filtering, nepomuk and all).

"By that logic you should only be able to view folders with it, but not do anything with the files inside (like open or move them), since you are only supposed to VIEW them. "

Not true, on database views, for instance, you can update views (insert, delete, update) like explained on wikipedia (updatable views section).

Well, to end this discussion, I do not think I am the "owner of the truth", I do like your idea with some adaptations, I proposed a solution (create a minimalistic file browser plasmoid or even make a desktop version of quickaccess, why not?), explained my points of view (which could be "right" or "wrong". So, to not make it an endless discution (we're walking on circles here... :D), I'm done (really done) and it was a pleasure to discuss this issue with you.

Answering FineX arguments:
 
"Augusto doesn't like the idea to change the target of folder view, instead Janne would like to see it extended with the possibility of use it like a file browser, did I understand right?"

Well, it is not about liking or disliking the idea. In fact, I like the idea of browser folder like Janne said. But it would be a file browser, that's what I am trying to explain, over and over again...

And just to correct, we can change the target of a folderview, what we can't do is browser folders. The target is static.

"If this is the point, you (Augusto and Janne) will continue to write your opinions without an end... :-) :-) :-) :-)"

I agree.. and that's very tiring...:D

"I suggest to Janne to write some use cases where navigating files through a plasmoid is useful. I suggest also to Augusto to write when this is not useful. "

I do think navigation files is useful, that's why I proposed the mini file browser. And it is not about "I am going to do that because its a useful thing"... otherwise, we would create a Frankstein or a car like that one Homer Simpson designed (all those things, including that big donnut, was useful for him).

"(I know you've already wrote when and when not on this long discussion, but, please, a short brief could be useful)."

You know what, I like you! :D

"From this point the actual system can be analyzed trying to understand if this issue will be useful for users, leaving on a side our personal wishes."

Well, I tried to explain why browsing and turning back automatically after some seconds, minutes or whatelse would make it very confusing to users (My gramma definitely wouldn't understand this, but she would understand dolphin opening when she clicked the folder).

Well, I left my personal wish on side from the beginning, I am trying to make this discussion based on some definitions and designs (NOT DOGMAS.. PLEEEASEEE), and even proposed a solution to make everyone happy. For me, it would make no difference to have this on folderview ( I am a power user and would configure this interval of time with no problem), but I DO think it would be very confusing for a major group of users (maybe I am wrong... just a user case research would make it clear... :D)


"Do you agree?"

I do!!! And I agree that this discussion is taking to long and being very tiring... So, let's leave it to the developers to decide.. maybe both of us are wrong and they show us an even better solution (you know, those guys keep amazing me with great solutions...)

Q:"So you ARE saying that folderview should only view folders, because it's called folderVIEW? That's like saying app called RSSnews should not handle Atom-feeds at all. " YEEEESSSSS, exactly that. It is called folder view because it is a view. As makes sense to call quickaccess, since it gives quickaccess to all the folders you want. Well, I expect something that's called RSSNews to atom-feeds, since that's what RSS is about, isn't it? As well as I expect a folderview to show me a view of a folder.

A:YEEEESSSSS, exactly that. It is called folder view because it is a view. As makes sense to call quickaccess, since it gives quickaccess to all the folders you want. Well, I expect something that's called RSSNews to atom-feeds, since that's what RSS is about, isn't it? As well as I expect a folderview to show me a view of a folder. 

Just read it and changed my mind, Not really Yeees, exactly... because there's a little diference between view folders and have a view of a folder, As I already explain.

So the answer would be, Partly yes... :D:D:D 

"I suggest to Janne to write some use cases where navigating files through a
plasmoid is useful."

Maybe not use-cases as such, but some rationale:

a) Enabling folder-browsing through the plasmoid would offer an alternative workflow for people, while not offering any drawbacks to people who are happy with the current system

b) Using folderview to open folders would simplify things, as user would not be presented by a new app-window. That app-window requires the user to refocus and re-orient himself, and it disrupts his workflow. Besides, new windows clutter the desktop and no-one wants to babysit app-windows (move them, close them etc.)

c) Quickaccess has shown that using plasmoid to navigate folders is perfectly doable

d) While Dolphin is pretty straightforward filemanager, there are times when user would prefer to do some really simple and quick filemanagement-tasks. Folderview already supports such tasks (copy/paste for example), and offering the user a possibility to open a folder inside the folderview would make those existing features fully functional.

e) While it could be said that this feature would make folderview more complicated, I'd say that the added complexity would be quite minimal. (I would guess 1-2 configuration-options and one UI-element at most in the actual folderview (a button that takes the view back to the default folder).

f) Creating a new "filemanager-plasmoid" would be pointless, since it would be 95% identical to the existing folderview-plasmoid. If we created new plasmoids for every combination of functionality, we would end up with lots of redudant plasmoids, that mostly replicate the functionality found in the other plasmoids. That multitude of choice would confuse the user. Instead of wasting time and energy in writing redundant plasmoids, we should try to make existing plasmoids better.

g) In many ways, opening the folder inside the folderview is what users expect, since folderview is a window on the desktop. The fact that folderview spans a new window (and app) to view the folder is somewhat similar if Dolphin opened a new window for each opened folder (and most users hate that behavior).

h) Enabling opening of folders would bring feature-parity between Quickaccess and Folderview. The two plasmoids are already very, very similar, with similar goals.

Why not just make quickaccess plasmoid works on the desktop then? It would solve the problem, extends the use of quickaccess to the desktop and we wouldn't be losing the reference (on quickaccess there's kinda a address bar on the top that shows where you are, and arrows to go back and forth). 

Note that what you see on folderview (on the top) isn't a addressbar, but a label. 

On KDE 4.2 you can even change the label of a folderview! Make a view of your Home folder and label it as "Those files and folders I really love to use!". This shows that it is indeed supposed to be static (No changes inside the view itself).

The way you want it - make it navigate and go back to default automatically after a few seconds - , we lose reference and depending on how many folders you navigate (say 15), you can really be lost.

I couldn't compile quickaccess here on my KDE, since I use 4.2 trunk, so I do not know if it comes back to "original" after a few seconds, nor how it behaves when opening many subfolders (maybe it works like those copy to menus, showing the various subfolders... do not know, could not see.. :( ) but taking only the pictures on kde-look.org, there's a reference (address bar and arrows) of where you are.

A view is like a picture, you can draw or erase some things on that picture, but make it turn another picture inside it (another folder.. so a completely different picture) without any reference... there's a good chance to get lost. 

 Reflection made me think of another solution... (other than file browser plasmoid).

Discussing this issue with my brother, he said that an elegant way to do it would be when you focus on a folder, it shows a preview of that folder on something like a ballon or menu (like those on copy to/move to - maybe a menu would be better... ballons take too much space) but without navigating inside the plasmoid itself. I thought that is very elegant and kinda what quickaccess does (maybe that's why they want to merge folder view and quickaccess.. do not know), we wouldn't lose the view/reference and it doesn't break the design of a view is. Would be like what those stacks of MacOSX do (but way more elegant)...

One technical/practical reason to not make folderview behaves like you suggested:

Suppose I browser, say, 13 subfolder (from Home folder, which is my default folderview folder) to reach a file that is on a 15th subfolder (Maybe I am a subfolder maniac!). On the 14th click, I notice that I just clicked the wrong folder!!! What to do?!?!?! How do I come back to the 13th so I can get the right 14th.. and then the right 15th subfolder??? Wait some seconds (say, 10 seconds ) come back to Home and browser all the 13 folders??! And if I get the wrong 5th subfolder on the second try? (so many subfolders.. easy to get lost) What if? What if??

Well, without a reference (a breadcrumb, a menu, a tree).. it could be VERY painful (I would open Dolphin itself, crying with anger, sadness and frustration!!).. One thing that is supposed to make my life easier, became a big source of pain...

Note that I never thought your main idea (have a minimalistic way of browser folders with folderview) was bad.. not at all.. I like the idea of having a minimalistic (and fast) way of browse files.. but the way you asked, suggested, is "wrong in concept" (and that's why I thought Kde team wouldn't do it).. because, once more.. it breaks the design (loses references).... Folderview itself (inside it) is not suposed to navigate files...

By the way, giving credits to Todd (third comment , I guess...) which had quite the same idea my brother and I had... That's all folks!

"Why not just make quickaccess plasmoid works on the desktop then?"

Developers already think that Quickaccess is just folderview in panel form-factor. So Quickaccess running on the desktop is.... folderview. And if we actually had quickaccess running on the desktop, users would be wondering "why do we have two plasmoids like this, when one is enough?". And if you told them that "one of these plasmoids simply views folders, the other also opens the folders", you would get a lot of puzzled looks in return....

"Discussing this issue with my brother, he said that an elegant way to do it would be when you focus on a folder, it shows a preview of that folder on something like a ballon or menu (like those on copy to/move to - maybe a menu would be better... ballons take too much space) but without navigating inside the plasmoid itself."

Why do I get the feeling that you are coming up with weird and complicated solutions to a simple problem, just so we could have a folderview that does not open folders? Why are you so fundamentally opposed to opening folders inside folderview, that instead of allowing that, you come up with solutions that are a lot more complicated and less useful?

Besides, previews like that are totally different when compared to how previews work everywhere else.

"Suppose I browser, say, 13 subfolder (from Home folder, which is my default folderview folder) to reach a file that is on a 15th subfolder (Maybe I am a subfolder maniac!). On the 14th click, I notice that I just clicked the wrong folder!!! What to do?!?!?!"

Please don't shout. One question mark and exclamation-point is quite enough.

As to your question... It is a valid question. But you need to keep in mind that folderview would still be very simple tool for very basic file/folder-related tasks. If the users wants to drill deep down in to the filesystem, he would obviously be better off using a proper filemanager. Folderview wouldn't be a replacement for Dolphin, it would just complement it.

Folderview would work if going 1-2 folders deep, but it doesn't really work if you want to go several folder deep, and then copy files to some totally different location. For those tasks we have Dolphin.

"but the way you asked, suggested, is "wrong in concept" (and that's why I thought Kde team wouldn't do it).. because, once more.. it breaks the design (loses references).... Folderview itself (inside it) is not suposed to navigate files... "

Again: you are stuck in a narrow definition, and you refuse to budge. By that logic, KDE-software should not run on Nokia's internet-tablets, since at one point, the goal of KDE was to create desktop-software for UNIX-like computers.

Instead of digging a hole and sitting in it ("folderview is supposed to only view folders, therefore it must NEVER open any folders!"), we should look at what makes sense and what would make the software better and more useful. Your complicated solution of previews and the like are just attempts to go around that definition, when the simplest solution would be to go straight through, and simply open the folder.

This change would not, in any shape or form, make folderview worse. The only objection seems to be that "folderview is only supposed to view folders,it must never open them".

Maybe integrating quick access to the folder view could be a compromise:
you enable the user to browse sub-directories of the current view which is not so bad, you keep the idea of "view" intact" but you allow to have access to a more wide set of files.

Examples based to how I organize my files:

* Folder view "Projects"
  - sub folders are the different projects, quickaccess allow to open files of each project

* Folder view "Customers"
  - sub folders are the different customers, quickaccess allow to open files of each customer

At this point, quickaccess could allow to browse to subdirectories :-)

Or we could simply make it so that user can open folders inside folderview, and be done with it. 

I think that the plan is that there will be just one folderview/quickaccess-plasmoid. If it's added to a panel, it will look like quickaccess does. If it's added to the desktop, it will look like folderview does. And since differentiating functionality of the plasmoid based on where the user happens to put it makes no sense, I would guess that both form-factors would support opening folders, since that functionality is supported by quickaccess. removing that functionality would make the plasmoid worse, when compared to current quickaccess.

" Please don't shout. One question mark and exclamation-point is quite enough."

Well, that's be problem of written communication. When I wrote that, I was pretty calm and didn't have the intention to offend... the exclamation-point was to show the user on that specific case was very desperate and surprised! 

If you felt like offended, I am really really sorry.. I won't put more than one question/explanation-point mart here.

"As to your question... It is a valid question." 

Is is a very valid user case, indeed. And it happens because of a very simple feature that is missing on your suggested solution... Be able to get access to just the previous folder (because there's no reference of where I am).

"But you need to keep in mind that folderview would still be very simple tool for very basic file/folder-related tasks. If the users wants to drill deep down in to the filesystem, he would obviously be better off using a proper filemanager. Folderview wouldn't be a replacement for Dolphin, it would just complement it. Folderview would work if going 1-2 folders deep"

Now I make you the question: Why a thing that is capable to open folders should be limited to a number of them? What's the point of having that at all then? Have access to 2 folders deep and not to the third would be weird. That would really break the workflow (if someone notice that folderview opens folder and opens 2 of them deep, he definitely would expect to open the 3rd). Breaking workflow was one of your reasons to suggest these changes of folderview. There's a confusion here of what is being simple and what is being limited.

It reminds me of Windows Starter edition. A thing that it also supposed to open apps, only open 3 of them. 

"Again: you are stuck in a narrow definition, and you refuse to budge. By that logic, KDE-software should not run on Nokia's internet-tablets, since at one point, the goal of KDE was to create desktop-software for UNIX-like computers."

I definitely can use this argument for you too. You refuse to budge and is stuck on "dogmas" (you just changed dogma to narrow definition... :D).
I gave you definitions (That I didn't invent.. but researched), I gave you links to explain those(wikipedia one), I gave you solutions (3 of them), gave you user cases and even agreed that a idea of having a way of browsing folder on plasma is good.. and you say KDE should not run on Nokia's tablets because it is supposed to work, for the beginning , on Unix-like systems? Well, who's resufing to budge here? 

"Instead of digging a hole and sitting in it ("folderview is supposed to only view folders, therefore it must NEVER open any folders!")..."

Folderview is supposed to show a view of a folder.. that's different. Don't know if you already used 4.2, but maybe when you see the label thing I explained before, it will be more clear. And it should never open folder inside itself, another difference. The way folderview works now already gives you a way to open folders (using dolphin, in this case). We're thinking of an alternative way...

"...we should look at what makes sense and what would make the software better and more useful"

That what we all I trying to do here, otherwise we wouldn't have such a long discussion. But reminds that design of a software is not JUST about being useful. It is one of the reasons... but we must follow some criteria (if we want a good and decent project), you know... all that software engineering stuff.

"our complicated solution of previews and the like are just attempts to go around that definition, when the simplest solution would be to go straight through, and simply open the folder. "

The "simplest" solution would not solve, because it would open only 1-2 folders.
It would add complication to the project (How to explain the user base that it opens only 2 folders deep? Why not 3?4? Put that on configuration? - Another parameter to set on configuration and a counter to know how many folder I navigate..." 

"This change would not, in any shape or form, make folderview worse."

Well, thinking about the "it only goes 1-2 folders deep" thing... I do think it makes folderview worse in shape, form and code. And already explained my point of view.

"The only objection seems to be that "folderview is only supposed to view folders,it must never open them". 

That was not the real objection. It must never open them INSIDE itself without any reference of what I am doing. That's different. Folderview already gives you a way to open folder (dolphin).


Well, you do want to see folderview behave like that, don't you?

I think you have the following options then (maybe there's more):

1) Wait for the KDE team to answer your wish and see if they will fulfill it. (I'll pay you a beer - or whatever you drink - if they develop this solution just the way you suggested).

2) If you are a coder, you can make it yourself. Opensource is beautiful.

3) If you are not a coder, maybe try the IRC channels, mailing lists, expose your point of view (it will be always welcome) and see if somebody is willing to do it for you (and whoever who likes your idea and agrees with you) and, maybe, make it available on Get hot new stuff.

Maybe plasma guys will read (if they have the patience) all these stuff we wrote here, get the ideas we had, mix it,  make a great solution and everybody will be happy (or maybe not...do not know).

Peace and love!




Well, in fact I found the ballon solution more complicated than the file browser plasmoid one.

""Again: you are stuck in a narrow definition, and you refuse to budge. By that logic, KDE-software should not run on Nokia's internet-tablets, since at one point, the goal of KDE was to create desktop-software for UNIX-like computers." 

I definitely can use this argument for you too. You refuse to budge and is stuck on "dogmas" (you just changed dogma to narrow definition... :D). I gave you definitions (That I didn't invent.. but researched), I gave you links to explain those(wikipedia one), I gave you solutions (3 of them), gave you user cases and even agreed that a idea of having a way of browsing folder on plasma is good.. and you say KDE should not run on Nokia's tablets because it is supposed to work, for the beginning , on Unix-like systems? Well, who's resufing to budge here? "

Just read the "By that logic" now, so ignore the "you say KDE should not run on Nokia's... 

But that doesn't change the fact that this "resuse to dodge" argument can be use against you (already explained).

@fineX: Maybe integrating quick access to the folder view could be a compromise:...

I agree, maybe that's what KDE people are discussing on mailing list (Don't know, did not read it yet).

I was just wondering how to make this integration, for instance, how would quickaccess appear:

On a ballon? menu? extending folderview height(like krunner - that would be weird :|)? 

Turn folderview into a mini browser (opening the folder inside the applet with a breadcrumbs on the top)? In this case. I'd rather separate the tasks and make a new plasmoid ( a mini browser plasmoid would be an "extended version" of the folderview)

One thing we got to be worried (always when you open folders) is the reference.  There MUST be a way to go back and forth, even if it is arrows buttons on the Top (Next, Previous)... just realized that it could also be a VERY simple solution... :D (although it kinda changes the definition of a view (NOT a narrow definition, but a scientific one that can be found on books of software engineering, database and even on wikipedia).

Well, that's it... 

Created attachment 28458 [details]
Integration mockup

This is a simple example which show how folderview could be integrated with quick access plasmoid.

@fineX: integrating mockup

MAAAAAAN!!! I LIKE YOU !!!! That's a very elegant and beautiful way to solve the problem!! THANK YOU THANK YOU FOR THIS MOCKUP!

That was kinda what I was thinking of too... but even better!!!

I thought I could make one mockup (i tried) but my artistic skills are too limited...

Your arguments were simple, direct and effective!! FAST AND FURIOUS argument.. CONGRATULATIONS!

You spoke a few words.. but was simply PERFECT. I think there could be a suggestion on the top of this wish to bypass all the comments and see your mockup instead.. :D

Anyway, this is only an idea. A suggestion to summarize this long thread. Now it is better to leave developers think if the feature technically doable, really needed and coherent with actual development plans (maybe there is already planned something which we don't know).

Goodbye :-)

"Now I make you the question: Why a thing that is capable to open folders should
be limited to a number of them? What's the point of having that at all then?"

I did not say a thing about imposing artificial limits on folder-navigation... If user wanted to drill down 20 folders with folderview, he could of course do so. But the user should realize that folderview would not be meant for complicated tasks like that. He could do it if he wanted to, but he might run in to issues (like the one you mentioned).

"Have access to 2 folders deep and not to the third would be weird. That would
really break the workflow (if someone notice that folderview opens folder and
opens 2 of them deep, he definitely would expect to open the 3rd)."

Again: Nowhere did I suggest anything of the sort. Nowhere did I say that there should be any kind of artificial limits. If user wanted to go 20 or 200 folders deep with just folderview, he could do it.

"It reminds me of Windows Starter edition. A thing that it also supposed to open
apps, only open 3 of them."

re-read my comment. I'm not suggesting any sort of limitations. Only limitations would be imposed by the users common sense.

"I definitely can use this argument for you too. You refuse to budge and is
stuck on "dogmas" (you just changed dogma to narrow definition... :D)."

My only "dogma" is to have software that is as good as it could be.

"Folderview is supposed to show a view of a folder.. that's different."

So the user shouldn't be able to open files using folderview? Opening files is not the same as viewing a folder.

Quick access seems to allow to drill down until you want... :-)

"re-read my comment. I'm not suggesting any sort of limitations. Only limitations would be imposed by the users common sense. "

Well, if the limitation of based of the "common sense" of the user, that user case I mentioned could really happen with a "nonsense" user...  Not thinking about that shows a terrible designed solution (it is like design a car and not think that a child could be inside it). :P 

Actually I don't see go deep on 3 subfolders not valid and common user case.. and your solution do not work if you navigate more than two folders (since we are just able to go back to the default first folder, not to the previous). It is like being able to just walk straight forward... with the possibility of  just go back to the beginning...




I think that the beautiful and pratical FineX mockup speaks for itself... so why not follow his intelligent suggestions too?

I'll copy it here:

"Anyway, this is only an idea. A suggestion to summarize this long thread. Now it is better to leave developers think if the feature technically doable, really needed and coherent with actual development plans (maybe there is already planned something which we don't know). "

Now I am really done here and happy because all this discussion had an happy and useful ending (the fineX mockup)...

Goodbye, and.. see you on another wishlist! or bug!

"Well, if the limitation of based of the "common sense" of the user, that user case I mentioned could really happen with a "nonsense" user... Not thinking about that shows a terrible designed solution (it is like design a car and not think that a child could be inside it). :P "

What you are doing right now, is basically same as if you complained about the fact that even though you can type text with Kmail, it doesn't really work as a full-blown word-processor, and therefore it sucks.

In short: Just because user might want to use some app in certain way, does not necessarily mean that it would be smart thing to do. And in this case, user would figure out when he should use folderview, and when he should se Dolphin.

Yes, you could open folders with folderview. But that doesn't change the fact that for more heavy-duty filemanagement we would still have a proper filemanager.

"Actually I don't see go deep on 3 subfolders not valid and common user case.. and your solution do not work if you navigate more than two folders (since we are just able to go back to the default first folder, not to the previous). It is like being able to just walk straight forward... with the possibility of just go back to the beginning... "

You are basically arguing that since folderview would not work for heavy-duty filemanagement, the idea should be scrapped. But like I said: for heavy-duty filemanagement we would still have Dolphin.

"I think that the beautiful and pratical FineX mockup speaks for itself... so why not follow his intelligent suggestions too? "

Because I don't understand what we are supposed to achieve with that mockup. Sure, it's a fine mockup, but why should we introduce a whole different UI and behavior to user? If you click on a folder in Dolphin, that folder is opnened. But in folderview, if you click on a folder, you get a list of folders instead? Why should we have two very different behaviors in two different places? Why should the user be suddenly be presented with a list of stuff, when he's clearly in icon-view? Why not simply open the folder?

This is a simpe task: Open a folder. Why are we then talking about complex solutions, when the obvious solution is simple as hell: just open the folder.

WOW! It's the 34th comment!

Well, I'm be short. Leave the decision to the developers then...

Goodbye

3 subfolders? Heavy-duty?

"If you click on a folder in Dolphin, that folder is opnened. But in folderview, if you click on a folder, you get a list of folders instead? Why should we have two very different behaviors in two different places?"

Because they are different things?

"Why should the user be suddenly be presented with a list of stuff, when he's clearly in icon-view? "

It's not an icon-view, its A view of ONE specific chosen folder. It's like a picture. I can take a picture of my mom, I can label it as "This is the most beautiful picture of my mom", write "Mom, I love you" on it, erase what I wrote and write "Mom, I love you even more each day", but I can't turn it into a picture of my Dad (This is pretty much what you do with folder view if you open a folder inside it, it a COMPLETELY different scene, since it is another completely different folder (not the one I chose on configs)). 


"Why not simply open the folder?"

Well, that's basically what the fineX mockup does, in a basic way (menus,it would give quickaccess to the folders inside the view), and makes sense because it is a plasmoid, not the whole filemanager.


Well, I really can't make myself more clear (and do not have time too! You know, it's Tuesday, many things to do)... so let's leave to the developers?

"3 subfolders? Heavy-duty? "

Drilling deep in to the filesystem is in many ways "heavy-duty". But you are no longer arguing this feature, but whether something is "heavy-duty" or not. It's completely besides the point.

"Because they are different things? "

But they do the same thing. In each case, the user is opening a folder. In one case the folder gets opened, in another case he gets a list of folders. We should strive for similar behavior that the user expects, as opposed to arbitrarily presenting the user with different behavior. 

User should be able to guess beforehand what his action will do. when he clicks on a folder, he expects it to be opened, not be presented by a list, that on a quick glance looks like a context-menu.

What happens if user clicks on a folder in Dolphin? It's opened. What if he clicks on it in file-dialog? It's opened. In each case, the folder is opened inside the window it's being clicked at. In Folderview it gets opened in a separate app, or, as you now suggest, it would not be opened at all, but the user would get a list of folders instead. That is totally different behavior when compared to everything else in the desktop. That is wrong, we should strive for consistency.

This is like on Windows, where each icon is opened with doubleclick. Except when they are in the taskbar, where you single-click. Most users don't understand the difference, and they double-click on icons that are in the taskbar. they do that because there is an arbitrary difference in behavior and they get confused.

"It's not an icon-view"

Yes it is. It's view with icons in it. It looks practically identical to the icon-view in Dolphin.

"its A view of ONE specific chosen folder. It's like a picture."

To users it looks identical to icon-view in a filemanager. And if it's just a picture, you shouldn't be able to select individual icons ont he view. But you can. So it's not a picture.

"Well, that's basically what the fineX mockup does, in a basic way (menus,it would give quickaccess to the folders inside the view), and makes sense because it is a plasmoid, not the whole filemanager. "

No, it does not make sense. It presents an new and arbitary change in behavior, all for the sake of avoiding opening the folder, because you are so hung on the word "view" if "folderview".

Like I have said before: your argument is about dogma. You are so hung on "folderview is just a view, it must not open any folders"-dogma that you are advocating complicated and arbitary solutions just so we could make sure that folderview does not open the folder. this dogma would prevent us from improving the software, while offering no benefits to the user. This is about making the software better. I haven't seen any explanations how the current system is better than what I'm advocating. And even if someone prefers the current scheme, he could keep on using it, since this could be configurable.

the simple and expected behavior would be to simply open the folder. No more, no less.

"You are so hung on "folderview is just a view, it must not open any folders"

Noooo, I am not hung.. :-D. It's the concept of view made by scientists, researches , written in books, and easily found on wikipedia and over the net. And folderview is a view (could it be simpler?)

And, for the (I lost count) times, folderview is just a view, it must not open folders INSIDE IT without any reference (which is different than it must not open ANY folder). It DOES GIVE a way of opening folders now (dolphin) and we would have a very elegant and coherent way of opening folders with quickaccess merged (fineX mockup) without breaking the definition and without losing the reference... 

You are SOOOO hung to YOUR wish (the way it is), that either you can't see the definition of view or you do not want to see it...

If you still do not believe it... take a look at this definition (which is not mine):

DEFINITION - In a database management system, a view is a way of PORTRAYING information in the database. This can be done by arranging the data items in a specific order, by highlighting certain items, or by showing only certain items...

By the way, this definition can be found here:

http://searchsqlserver.techtarget.com/sDefinition/0,,sid87_gci928676,00.html

Now, take that for a folder, not a database management system...

"...So it's not a picture. "

Taking the definition for a folder.

Folderview is a way of PORTRAYING information of a folder. This can be done by arranging the data items in a specific order, by highlighting certain items (mine: quickaccess would be a way of highlighting a subfolder) , or by showing only certain items...

"And if it's just a picture, you shouldn't be able to select individual icons ont he view."

You just said I can't write "Mom, I love you so much" on my mom's portrait... :-(. Or even more specific, I can't draw a heart highlighting my beautiful mom's face... or even better, taking the definition:

...This can be done by arranging the data items in a specific order, by highlighting certain items ...

When using nepomuk in folder view, it will kinda be the same as a view of a database.

You can find the definition of view on many many sources over and over on the internet...

As well as views could be used on database systems, now we can do that on plasma with folderview!! Folderview is an example of how a view can be used in plasma (for folders). There could be implemented another kinds of views ...

That's it.. I'm done.. I'm exhausted... That's reaally all (for the "I lost count" time)... but now I REALLY mean it.. :-D:-D


Love and Peace!

PS.: When I use CAPS, I am not shouting, it is just to emphasize... so, don't take it personal...

"And, for the (I lost count) times, folderview is just a view, it must not open folders INSIDE IT without any reference"

It could have a reference.

"It DOES GIVE a way of opening folders now (dolphin) and we would have a very elegant and coherent way of opening folders with quickaccess merged (fineX mockup) without breaking the definition and without losing the reference... "

The mockup presents a behavior that is totally different from similar behavior everywhere else in the desktop for no real benefit to the user. It's only purpose is to satisfy a narrow definition of what folderview is and what it should do. And in doing so it makes the system more complicated and totally different from every other system in the desktop.

Folderview could be a list (like quickaccess is right now), or it could be an icon-view (like folderview is right now), but it couldn't really be both at the same time.

"DEFINITION - In a database management system, a view is a way of PORTRAYING information in the database."

What do databases have to do with this? We are not talking about a database.

"Folderview is a way of PORTRAYING information of a folder."

If folderview was just about that, you would not be able to select stuff being displayed in folderview. It would be just that: a picture showing the contents of the folder. But we all know that folderview does more than that.

But this is still about you stubbornly having a narrow definition for folderview and that definition should not be changed at all. Anything that would expand what folderview does should be shunned, since "that is not what folderview is about".

We are talking about very simple thing here. When user clicks on a folder in folderview, folderview would open that folder. No more, no less. I really don't understand why this simple request spawned a huge discussion about what folderview is and isn't. I would understand discussion about how to implement it and the like, but so far this discussion has been about you telling me that "folderview must not open any folders because folderview is just a view"...

If you didn't noticed, I already gave up explainning... Well, I bet fineX understood my point and as a result made that awesome muckup :-D... (let's stop it, will we?)

So, peace and love... 

"narrow defitinion"...

NO, scientific one..

"but so far this discussion has been about you telling me that "folderview must not open any folders because folderview is just a view"... "

Are you really REALLY reading my comments?







Well then... you are right and I am wrong!! :-) :-)

Janne wins

... Flawless Victory...
... FATALITY ...

:-) :-)

PS.: I even gave 20 votes to your wish.

now that everyone has had their say ....

Simply I love you Aaron :-)

In case somebody didn't notice, I was being sarcastic/ironic on comment #41

:-)

Aaron: Can you give us a reason? No, I'm not going to argue with you about this, since I recognize that you are the King of this particular hill :). But I would like to know whether the approach is wrong or something.

Janne: it's a simple view meant to be a starting point, a launching pad if you will. it's a shortcut, not a manager.

now, while a full file manager on the desktop layer would likely be rather cool for many people, it would also eliminate the simplicity and elegance of folderview for many more while making the code a *lot* more complex; not to mention to think about how to deal with it as a desktop containment (remember that one of the use cases is to replace the legacy desktop for people).

a separate "manager and a bad of chips" plasmoid, even one that shared much of the code with folderview, would be neat and i'm sure the love child for many a power user out there. it's just not what folderview is, nor who it is for.

OK, thank you Aaron.

*** Bug 178231 has been marked as a duplicate of this bug. ***

Created attachment 29745 [details]
Mockup of browsing folder view

(See attached mockup)

I'd be fine with this as a separate plasmoid, but I do think I can see a number of use cases for this. Mine:

I have a 'School' folder with sub folders for all my courses and each has a few files:

School
> Course
> > Lectures.txt
> > Readings.txt
> > Cases.txt
> Course 2
> Course 3
> Etc

If folder view could browse, then I could just click on my course and click on the file I want to edit right on the desktop. No need to launch a file browser and no need to have six folder views on my 12" laptop screen. I'd just open my laptop and in two clicks I would have my notes open.

Its uses would be limited. You wouldn't likely want to use it to poke around the whole file system. But within a small tree of folders it would be very useful.

You could use the same back button that is used almost everywhere else in KDE4. You could even use the breadcrumbs that are already in the title of the folder view. After a few seconds it can revert to the original view. You could leave the back button so that if the person wants the last sub-view back then they just press back.

I just think that it would make the folder view plasmoid a lot more useful.

In related note, Apple is implementing an equivalent feature in OS X 10.6. See here:

http://www.macrumors.com/2009/02/12/snow-leopard-adds-minor-often-requested-tweaks-put-back-stack-folder-navigation/

"Stacks Folder Navigation - The introduction of the "Stacks" metaphor in Mac OS 10.5 was met with mixed reactions. One issue with Stacks has been the inability to "drill down" into additional folders. In Leopard, clicking on a folder in Stacks simply opened that folder in the Finder.

According to those familiar with the latest developer build, clicking on a folder in Stacks smoothly opens the new folder in Stacks while shrinking the parent window as a small icon on the top left. This allows you to quickly navigate in and out of folders in Stacks."

*** Bug 220228 has been marked as a duplicate of this bug. ***

*** Bug 184380 has been marked as a duplicate of this bug. ***

It looks like all discussion on this has ceased. Too bad, because I think the idea is a must. The point of folderview should be to give quick and convenient access to files *from anywhere, in any activity, on any desktop*. It should therefore allow one to drill into folders without opening the file manager.