Thanks, I'll add this to the correct component so the right people see this.

@Eike: Sorry if already implemented, I didn't check this report.

Created attachment 92693 [details]
KDE 4 Folderview widget accessed from panel

To clarify my original post:  my complaint pertains to the behaviour of the Folderview widget accessed from the panel in Plasma 5 which differs from its behaviour in KDE4 in that with the latter it was a vertical drop-down (or popup depending on the location of the panel) single list of folder icons the full length of the screen whereas in Plasma 5 it is a drop-down scrollable rectangle with icons arranged in rows.   The wish is for it to return to its behaviour in KDE4 when accessed from the panel - or at least for that to be an option.  When the folders are displayed thus as one vertical list they can be selected faster.  Please see attached images.

Created attachment 92694 [details]
Plasma 5 Folderview widget accessed from panel

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

+1

The flat list with one item per line is far more usable than a scattered bunch of icons with filenames split into multiple lines below them, and lots of space in between... the latter, for me, is useless.

In my plasma 4 setup I used something like the screenshot that SP attached, and even moreso - using the smallest icon size, which made it even more compact, with room for more items on the list.

Also, the folders within the menu were navigable within the same list, i.e. selecting a folder would replace the menu contents with the selected folder's contents (and there was an option to go back up). Selecting the menu title would open the folder in Dolphin. In the new plasma 5 widget, on the other hand, selecting a folder opens it in dolphin, unless you manage to click on the tiny diagonal arrow which causes another popup window on top of the first popup window which makes things even messier. It's much harder to drill down to the folder you're looking for before launching it in dolphin, if that's what you're trying to do.

Traversing within dolphin just splits the experience in two (some traversing in folder widget, some traversing in dolphin) which makes for a worse user experience than using the widget alone.

In short - bring back all the functionality from the plasma 4 widget :-)
(at least as an option)

There are currently no immediate plans to bring back list mode, but I do appreciate the utility and it may happen in the future. It's certainly quite doable from a tech POV, and much, much less work than it was in the Plasma 4 version.

I'm sorry to hear there are no plans for this. I was using it daily as part of my workflow (even had a few of those widgets with different folders). Current widget is useless in that sense - way too much scrolling icons and hunting down names.

As a workaround, I thought of just using dolphin launchers in the meanwhile and working with the dolphin standard list view - but at least offhand, I don't see where to configure the dolphin launcher icon to open a specific base folder when clicked. Is this possible?

I love KDE Plasma.  A PC is just that - a PERSONAL Computer and should have a DE that is configurable to the user's specific needs.  KDE Plasma traditionally allows all this and more - in comparison to some other DE's that box the user in.   I have configured my Plasma4  desktop according to my aesthetic and functional requirements.  There is nothing on it except for a background   and whatever programs I have open in a particular Desktop or   Activity.  The vertical drop-down list in the Folder-view widget on the panel affords at-a-glance access to my main folders.  No dithering from left to right required.
I have so far installed Plasma 5 on two test machines and Fedora 22 with Plasma on one of them.  There is no way I am going to upgrade my main computers to either until these things are resolved.  To do so would be to lose the tailored functionality I already have in KDE Plasma 4.  The Folder-View is just one bugbear and an important one for me.  The Dashboard is another.  Whatever happened to the option to allow a separate set of widgets for the Dashboard?  I am sure the developers are swamped with so many things in this complete overhaul of Plasma and that they will find their way to resolve these issues eventually.  As an end user I am extremely grateful to the KDE developers and community for their dedication.  I do believe, however, that Plasma 5 is just incomplete and not ready yet for general release.  It is a pity that upgrading to Fedora 22 automatically upgrades Plasma to 5.  There are many unsuspecting users who did the upgrade screaming on various lists right now.

I don't know how many KDE devs are gonna see this here, but I'd like to say that I totally agree with SP. Unfortunately, Kubuntu 14.10 stops being supported in one month, so I could not postpone the upgrade any longer without being open to security vulnerabilities. That is the only reason I upgraded at this time. I originally upgraded my laptop a month ago, and just like with my eventual upgrade to my desktop yesterday, it totally felt like it's a step backwards. Nearly every widget or configuration I use (and they are quite standard for the most part - clock, taskbar, folder view, notifications, wallpaper, standard system tray icons, etc. - all quite mainstream) had functionality simply removed, making it somewhere between less usable to totally useless.

I also greatly appreciate all the work the KDE devs have been doing for years, making the dream of a great, feature-rich and customizable FLOSS desktop real. but I do agree - there are just so many things missing or ruined in plasma 5 that I would never call it release-ready. And it's not even version 5.0.0 we're talking about, but 5.3.1. After so much bad PR with KDE 4, I just don't understand how this community found itself in the same position of releasing a half-baked platform way too early. I really wish they'd have waited until it's fully-baked and delicious as the version it is replacing eventually became before going public.

Here's to hoping that the dropped functionality will be re-added quickly, and the shortcomings fixed, and that when it's all back to its former glory, it will be here to stay and not changed for the sake of change again with plasma 6.

Please keep your comments relevant to the bug; reading long and mostly unrelated comments is not helping people doing bug triage.

Eike - as you say "It's certainly quite doable from a tech POV, and much, much less work than it was", could you perhaps list the steps that would be required for this change? Maybe someone might pick up on this.

That said, I too would welcome this mode.

Yeah folks, trying to guilt people never motivates them to work faster, just for the record.

> had functionality simply removed

No, nearly every plasmoid you use got rewritten from scratch or nearly so, and in some cases had functionality either not added back yet, or quite possibly won't. In the meantime, a lot of them also had their quality bar raised significantly or other functionality added that was never there previously and had plenty of others clamoring for it. 

> could you perhaps list the steps that would be required for this change? 

It's mostly down to:
- Different layout in the delegate to be useful as a row delegate
- Different default sizing for the popup case (that in conjunction with the delegate makes the grid view use one column)
- A few lines of code to make running directory items change the model url instead of KRun'ing them
- Setting some knobs differently depending on the popup constraints (e.g. the column flow)
- Parameterizing the config UI since not all of the options make sense in popup mode at that point
- Most likely some behavioral stuff like switching off the rubberband

I apologize - guilt was not the intention. You guys are doing a great job. I just thought it was important to bring to your awareness the divide between how devs see plasma 5 (a huge technical step forward) and how users currently experience it (a big functionality and usability step backwards), so that you may be able to better communicate and sync the expectations and roadmap, so that everyone knows where this is at, and where it is heading and make appropriate choices instead of just being frustrated and losing faith (and market share). I hope this makes sense to you guys :-)

Git commit d37928b252e69b3def16de0576e76173f5fd9e77 by Eike Hein.
Committed on 03/06/2015 at 21:48.
Pushed by hein into branch 'master'.

Style as list view when constrained in a popup.

In list view mode, Folder View navigates in-place (that is,
activating a directory item will move into that directory)
rather than use preview popups.

Also some fixes for showing only relevant actions in the
context menu depending on (containment, floating, popup)
constraints.

M  +10   -0    containments/desktop/package/contents/ui/ConfigIcons.qml
M  +57   -14   containments/desktop/package/contents/ui/FolderItemDelegate.qml
M  +63   -15   containments/desktop/package/contents/ui/FolderView.qml
M  +16   -2    containments/desktop/package/contents/ui/FolderViewLayer.qml
A  +111  -0    containments/desktop/package/contents/ui/UpButtonItem.qml     [License: GPL (v2+)]
M  +20   -2    containments/desktop/package/contents/ui/main.qml
M  +49   -12   containments/desktop/plugins/folder/foldermodel.cpp
M  +9    -0    containments/desktop/plugins/folder/foldermodel.h
M  +1    -1    containments/desktop/plugins/folder/positioner.cpp
M  +29   -0    containments/desktop/plugins/folder/viewpropertiesmenu.cpp
M  +11   -0    containments/desktop/plugins/folder/viewpropertiesmenu.h

http://commits.kde.org/plasma-desktop/d37928b252e69b3def16de0576e76173f5fd9e77

Blog post with screenshots: https://blogs.kde.org/2015/06/04/folder-view-panel-popups-are-list-views-again

FWIW, I went back and looked at what Plasma 4 did, couldn't find in-place nav as described in comment #6. I implemented it anyway since it seemed like a nice idea.

Wow, that sounds great! Thank you so much for rising to the challenge, and doing it so quickly too!!

In-place nav? Something like Kickoff's breadcrumb bar in the app list?

See comment #15.

(In reply to Eike Hein from comment #15)
> Blog post with screenshots:
> https://blogs.kde.org/2015/06/04/folder-view-panel-popups-are-list-views-
> again
> 
> FWIW, I went back and looked at what Plasma 4 did, couldn't find in-place
> nav as described in comment #6. I implemented it anyway since it seemed like
> a nice idea.

Thank you so much Elke.  Many thanks.  This really makes me happy :)

It's now also possible to configure the panel button icon, and use middle-click to always run (i.e. open in Dolphin) a directory item instead of cd'ing into it.

(In reply to Eike Hein from comment #20)
> It's now also possible to configure the panel button icon, and use
> middle-click to always run (i.e. open in Dolphin) a directory item instead
> of cd'ing into it.

Brilliant, Eike.  Is it possible to download the updated folder-view widget separately before the release of 3.4 or is it better to wait because of associated dependencies?

About half of it is C++ code, so it has to be built from source unfortunately. It would be possible to build it against 5.3, though. Note that one unified codebase provides the Desktop containment, the Folder View containment, the Folder View desktop widget and the Folder View panel widget.

I've also made the delegate appearance more consistent with Kicker, improved the default sizing and some margins, and added the window pin tool button to the title area. There are updated shots in the blog post.

Awesome! I was gonna ask for those enhancements, but didn't want to push it :-)
You rock, Eike!

^ Not afraid of more enhancement requests ;)

It's pretty fun to use so far - I set up two panel folders with custom icons myself now!

Alrighty then :-)

What is the 'ehs1 on ehs1' part on top mean? It looks like there's a mix of greater-than and slash in the path. It would be great if there were full breadcrumbs up there, like in dolphin or k-menu (which someone mentioned above). Maybe that's already the case, can't tell from the screenshot (I haven't compiled it to test myself).

The Folder View title settings have several modes including full path and custom title -- in "Default" mode it generates a 'pretty' title in the format "<best matching Places entry> > <path below>". "ehs1 on ehs1" is a Samba share named ehs1 on a server named ehs1 here in my home -- that's how it shows up in Places (so e.g. also the Dolphin sidebar). This title format is matching what the Plasma 4 implementation did.

I'm currently not planning to implement a full breadcrumb navigation bar, to be honest :). Reasons:

* The ability to navigate down is handy, but the purpose really is quick access, not to replace Dolphin. Any navigation in the popup will mostly be straight to a target known in advance, and the view is also reset when the popup closes. I just don't think there's a lot of need to cater to heavy up/down/sideways navigation. If you're in for a serious file browsing session, it's easy to open Dolphin for the location you're at.

* The popup is much more space-constrained than a file manager window, and there's not a lot of space to actually sensibly fit a useful breadcrumb bar. With a title label handling overflow by eliding the text in the middle is fine, with a breadcrumb bar that doesn't really fly.

* A breadcrumb bar wouldn't satisfy the other modes of the title label (e.g. custom text) so you can't really swap out one for the other anyway, and having both would make the UI rather busy. I think - keeping in mind the paramount goal here is quick access utility - this UI benefits from staying simple, since it's easier to comprehend at a glance then.

Well, you said we can ask for more, so I did :-)

But I basically agree with the points above, and crumbs are definitely not a must.

It looks like you've already returned the widget to being very useful, the rest is just little tweaks... maybe we'll come up with more ideas after it's released and in wide use for a while.

Thanks again for all your work on this!

BTW the Kubuntu folks do weekly ISOs of the latest git code; there *should* be a new one tomorrow that hopefully includes the latest commits, so you could alpha-test it via a live CD tomorrow.

(In reply to Eike Hein from comment #29)
> BTW the Kubuntu folks do weekly ISOs of the latest git code; there *should*
> be a new one tomorrow that hopefully includes the latest commits, so you
> could alpha-test it via a live CD tomorrow.

Eike - is it possible to download the source and compile it and from where?  I would like to test it on the two machines on which I have Plasma5 running.  One has Fedora 21 and the other Fedora 22.

>  Eike - is it possible to download the source and compile it and from where?

Yes. Roughly like this:

1. Clone git://anongit.kde.org/plasma-desktop
2. Grab build dependencies, on Fedora 'yum-builddep plasma-desktop' probably does the trick
3. cd <clone>; mkdir build; cd build; cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=$HOME/foo ../ 
4. cd into containments/ in the build(!) dir, run 'make install' within to build and install only the containments into the prefix used above
5. Stuff something like https://paste.kde.org/puib5apru/siofmg into your /etc/profile.d/ or (smarter) into a *.sh file in ~/.config/plasma-workspace/env/ (mkdir if necessary) 
6. Log out of Plasma and back in
7. You're now using a self-built Folder View

(In reply to Eike Hein from comment #31)
> >  Eike - is it possible to download the source and compile it and from where?
> 
> Yes. Roughly like this:
> 
> 1. Clone git://anongit.kde.org/plasma-desktop
> 2. Grab build dependencies, on Fedora 'yum-builddep plasma-desktop' probably
> does the trick
> 3. cd <clone>; mkdir build; cd build; cmake -DCMAKE_BUILD_TYPE=debug
> -DCMAKE_INSTALL_PREFIX=$HOME/foo ../ 
> 4. cd into containments/ in the build(!) dir, run 'make install' within to
> build and install only the containments into the prefix used above
> 5. Stuff something like https://paste.kde.org/puib5apru/siofmg into your
> /etc/profile.d/ or (smarter) into a *.sh file in
> ~/.config/plasma-workspace/env/ (mkdir if necessary) 
> 6. Log out of Plasma and back in
> 7. You're now using a self-built Folder View

Great!  I followed the instructions and installed the new folder widget on FC21 KDE Plasma5.  Love the enhanced navigability - it works very well.  One minor cosmetic detail - I notice that the Icon Text feature for Lines, Color, and Shadows present in KDE4 is missing here.    But as I said - this is minor.  Thanks again for coding these improvements.  Your work is very much appreciated.

^ They're dynamically hidden when the widget is in a panel, because I decided it makes sense to make the delegate match Application Menu (Kicker, the alternate menu) closely. If Folder View is used as desktop containment or desktop widget, the configurability is there (except for Shadows -- the KDE 4 version didn't have shadow config exposed upstream, although some distros like Netrunner patched that in -- meanwhile, the P5 version simply has no shadows anyway because the VDG decided on a different look).

And you're very welcome BTW - it's fun to make things that get used.

Perhaps this is outside the scope of this discussion - as it is a VDG issue - but the "Shadows" feature in the KDE4 version of Folderview appears to be a highlight behind the lettering.  This makes it easier to read dark text when you have a translucent dropdown on a dark or grey background.

(In reply to SP from comment #34)
> Perhaps this is outside the scope of this discussion - as it is a VDG issue
> - but the "Shadows" feature in the KDE4 version of Folderview appears to be
> a highlight behind the lettering.  This makes it easier to read dark text
> when you have a translucent dropdown on a dark or grey background.

As can be seen in the attached image I posted earlier