[kde-linux] "Dir Filter" has gone missing in 4.7.3 +

[Duncan]

James Tyrer posted on Fri, 18 Nov 2011 22:44:57 -0700 as excerpted:

> I have to ask, is my Steve Jobs like attitude totally unacceptable in an
> OSS project.  I just have to think that this is version 4.7.x and this
> little basic stuff should be working 100% by now.

> But, there is a faction that doesn't want to do any more work on
> Konqueror but rather just have Dolphin an Rekonq.

FWIW, I think the whole kde4 thing will go down as a transitional and 
troubled time in kde history, due to the new-and-shiny but never more 
than 80% since by then it's off to the next new-and-shiny.  Also 
troubling is that a large segment of the developers seem focused on 
mobile now, not bad in itself (rather, good), but bad when it's to the 
exclusion of the desktop, as it seems to be some of the time.

Qt5 and kde5 are in the works, tho.  Qt is now a community project, 
released from the bonds of nokia, and from what I've read, they've 
settled down development of new platforms there, to focus on what they 
have, at least for now.  That's a good thing.  And while the credibility 
of kde regarding promises is about zero these days due to the headlined 
kde3 support as long as there are users promise, then instead, dropping 
it like it was a radioactive lump of plutonium or something, they /say/ 
that kde5 will be much more incremental, much more focused on building on 
what has gone before, instead of going for the latest shiny.  That's 
good, because they definitely NEED it.  But we'll have to see.  As I 
said, credibility is hovering right about zero ATM, so I don't think 
anyone that went thru the kde3->kde4 mess at least, is holding their 
breath.

But while I expect konqueror to stay around for kde4 for compatibility 
reasons, if in a lower profile and sometimes broken state, it'll be real 
interesting to see whatbetter they do with kde5 in this area.  Personally 
speaking, on the browser side I'd like to see them focus on better 
integration with something with more mainstream support, either firefox, 
or more likely in practice, chromium or something webkit oriented (rekonq, 
but it has a LONG way to go to fill that role).  I'd *REALLY* like to see 
them either go with chromium/firefox directly, or at LEAST integrate full 
support of extensions for the chosen solution, as face it, the extensions 
are a lot of what make the browser these days, and kde simply DOES NOT 
and WILL NOT in the foreseeable future have the market share to properly 
support a healthy and viable extensions community of its own.  Thus, the 
browser they integrate MUST at least be generally extensions compatible 
with a browser with a far larger market share (basically chromium or 
firefox), if it's not direct integration of that browser, or the kde-
integrated solution is simply not going to be user-viable, long term.

Because right now, I've switched to firefox as my primary browser, 
mainly /because/ of the plugins (noscript being the biggest one for me, 
but there are others), but I *REALLY* miss the full integration, being 
able to bookmark it in the browser and just "magically" show up in the 
bookmarks menu I have setup in plasma (classic menu, set to show 
bookmarks only), have krunner auto-search the browser bookmarks, have the 
web shortcuts integrate with the browser, etc, just as it does when the 
default browser is konqueror.

But it's quite clear that few kde devs actually use konqueror as their 
main browser, or serious bugs like the lack of a proper security 
certificate management gui, in an age where whole certificate authorities 
are getting compromised and having their certs revoked, wouldn't continue 
to exist for several major versions after kde was declared ready for 
ordinary use and users.  Similarly with the "stable" update that 
introduced the double-form-submission bug, with users having to wait an 
entire month or more for the bugfix update.  Obviously, konqueror is 
considered no more than a toy, or these sorts of bugs and their continued 
existence wouldn't be considered tolerable.  But since konqueror IS no 
more than a toy to them, well, it doesn't matter how long it takes for 
such critical bugs to be resolved, because a "real" browser is expected 
to be used instead.  (And FWIW, rekonq is considered less mature than 
konqueror, or at least was while the cert thing was a problem, so it 
couldn't be the answer either.  Instead, a "real" browser such as firefox 
or chrome/chromium was assumed to be the default.)

For file management, I expect dolphin to continue as the kde5 default, 
but get more focus, with konqueror either dropped or perhaps best for it, 
adopted for independent development with a status much like that of 
krusader.  But the heavier focus on dolphin and further dropping of focus 
on konqueror will likely result in a more functional dolphin that can 
more effectively replace the kde3-traditional konqueror, for file 
browsing, anyway.

I'd also like gwenview to support standard file browsing, while expanding 
its image focus to media in general.  Right now, it doesn't work as a 
regular file manager, because it only shows images and video, not even 
audio-only media.  Keeping a media-only mode but expanding it to manage 
audio files and possibly to show text files for their README relationship 
to media would be good, but a general filer mode, showing all files much 
like dolphin does, would be good as well, and allow it as a much more 
workable file manager when chosen as the default file manager in the 
default application settings.  Because once that's possible, I'll very 
likely set gwenview as my default file manager, as it'll work fine for 
"user mode" file management then, and I already have mc for "sysadmin 
mode" file management.  Then I'd not need dolphin or konqueror as file 
managers at all.

It'll also be interesting to see what they do with phonon, for instance.  
My last reply was to a guy on the gentoo-desktop list, running fvwm as 
his window manager, with jack-audio, and trying to use some kde apps 
including kaffeine, but having problems with phonon not working on fvwm, 
only if he started a kde session.  Qt4 had adopted phonon for a time, but 
then decided it wasn't a good fit for mobile so deemphasized it in favor 
of qt-multimedia.  But with the community focus now for qt5, and a 
refocus on supporting existing platforms instead of porting to new ones, 
particularly mobile, will they continue to emphasize qt-multimedia for 
qt5, perhaps dropping qt-phonon, or will they refocus on qt-phonon, 
or...?  And what will kde5 do as a result?

Meanwhile, there's talk of integrating far more functionality from kdelibs 
into qt, making qt5 far more its own integrated environment while 
reducing the weight of kdelibs substantially, but even if they do go that 
route, it remains to be seen how much of it they'll get in qt5, at least 
the initial version, and how much might remain for qt6 or qt5 updates.

In any case, it'll certainly be interesting to watch as qt5 and kde5 
unfold.  Will they refocus on the desktop and stabilizing existing 
functionality and users, or only treat the desktop as an afterthought as 
they continue to focus on mobile, the new shiny?  Meanwhile, the new-
shiny of tablets will surely fade in a couple years, and one can only 
hope that semantic-desktop will either fade, or make *DRAMATIC* gains in 
stability, while reducing its resources piggishness.  What will replace 
those as the new-shiny, and will everyone be off to follow them, too, 
dropping everything else to afterthought status as it seems the 
traditional desktop is ATM?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman